-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Auth error when scoped private package has unscoped name in package.json #8258
Comments
Have debugged this and I think I can see why NpmRegistry.request is failing to send the token.
The scope has been stripped off packageName for the fetch request. This means that NpmRegistry.request doesn't think it is a scoped request that needs authentication, and even if it did (by setting 'alwaysAuth') it can't find an auth token using I have nowhere near enough of an idea about yarn internals to know if the issue is that the fetcher is passing the un-scoped package name, or the request method needs to be smarter about finding an auth token for this path/name combination. I have a fix that works for me by having NpmRegistry.request decide if the package is scoped and, if so which token to use based on pathname as well as packageName, but have no idea if this the actual fix or a band-aid for a problem elsewhere. It does however seem to fix this issue and doesn't cause any test regressions, should I submit a pull request? |
This wasn't really a yarn issue. Somehow a package in github package manager with the scoped @MY_ORG/MY_PACAKGE url, but with (unscoped):
in package.json had been created. Npm was happy to publish this, yarn failed with this issue when I tried to use it. Maybe an error check somewhere during package resolution would be a good idea? |
i had the same issue .but the definition of the package is:
it install good with:
|
cache problem i solved |
I had the same problem, so thankful for this thread 🤝 Turns out a package is published for example with this package name |
Another ah ha moment for me using private scoped github package registry packages was found here: yarnpkg/berry#316 (comment) Using yarn 3, you don't have to use
I know Also another thing to note is yarn doesn't handle adding things to the |
Bug description
Dependencies on private packages fail for (at least) github package manager with an authorization error during fetch phase.
I have a project that has a dependency on a private package hosted on the Github package manager.
npm install
is able to access this package using my config,yarn install
cannot.This is sort of a dup of previous issues like #4451 (there are several non-overlapping issues about private package registry auth that I found trying to debug it).
This is a specific reproducible case and I think I have a vague idea of the code issue, so opening a new issue. Please merge it with an older open issue if it overlaps.
Config
user .npmrc:
project dir .npmrc:
What I've Tried
Every permutation of .npmrc/.yarnrc suggested by the various issues/how-to's here and on stackoverflow with several different versions of yarn has been tried (registry with/without trailing slash, private registry org name etc etc). The most working I can get it, fails like this on all yarn versions including current yarn master (MY_GITHUB_TOKEN, MY_ORG, and MY_PACKAGE are anonymisations of valid Github User Token, Private Package Org, Package name, to protect the innocent)..
Command
Further immediately after the above fails, I can fetch the package manually using the token:
works and fetches the package (well gives me a 302 redirect to an aws bucket which then works).
Yarn seems to have the right config to fetch the package:
It is only the fetching phase that fails to send the token, it apparently successfully auths to npm.pkg.github.com during package resolution. --verbose tells me:
Environment
12.17.0
1.23.0-0
MacOS
Several versions of yarn tried, up to 1.22.3, error is slightly different (checksum error masks 401), but 1.22.4 and current master head both give same 401 result.
The text was updated successfully, but these errors were encountered: