Berry: [Bug] Can't resolve private packages

[bengry]

Describe the bug
We're trying to upgrade our project to Yarn v2, and part of our dependencies are private packages we published under npmjs.org (private scope, under an authentication with a token).

To Reproduce

The setup is this:
~/.yarnrc.yml (global user-level config file, with secret tokens etc.):

npmRegistryServer: "https://registry.npmjs.org"

npmRegistries:
  //registry.npmjs.org:
    npmAlwaysAuth: true
    npmAuthToken: <secret-token>

<path-to-project-root>/package.json:

{
  "name": "yarn-pnp-private-package-repro",
  "dependencies": {
    "@our-scope/foo": "^1.0.0"
  }
}

When I run yarn in the repo I get this:

> yarn
➤ YN0000: ┌ Resolution step
➤ YN0001: │ HTTPError: @our-scope/foo@npm:^1.0.0: Response code 404 (Not Found)
    at EventEmitter.<anonymous> (/private/tmp/yarn-pnp-aliased-package-repro/.yarn/releases/yarn-berry.js:24:323118)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
➤ YN0000: └ Completed in 0.34s
➤ YN0000: Failed with errors in 0.34s

Environment if relevant (please complete the following information):

• OS: OSX
• Node version v12.14.1
• Yarn version 2.0.0-rc.27

[arcanis]

Interesting - can you run yarn set version from sources --no-minify and add console.log statements in httpUtils to figure out what request is Yarn doing (url and auth headers, mostly)?

I'll add a way to debug this more easily.

[bengry]

@arcanis The private package name in request for this case is @brandtotal/frontend-common, so the below will reflect that. I added a bunch of logs along the way, and saw this request being made:
URL: https://registry.npmjs.org/@brandtotal%2ffrontend-common
Headers:

{
  authorization: 'Bearer <secret-from-npmjs.org>'
}

the secret is the same value I have in .yarnrc.yml:

npmRegistryServer: "https://registry.npmjs.org"

npmRegistries:
  //registry.npmjs.org:
    npmAlwaysAuth: true
    npmAuthToken: <secret-from-npmjs.org>

[arcanis]

It seems legit, I'm not sure what might go wrong without reproduction case 🤔 My main guess would be that the target package has a typo, but that's probably unlikely ...

[gdorsi]

I have a similar issue:

.yarnrc.yml:

npmRegistries:
  //npm.my-company.io/:
    npmAlwaysAuth: true
    npmAuthToken: <token>

npmScopes:
  my-company:
    npmPublishRegistry: "https://npm.my-company.io/"
    npmRegistryServer: "https://npm.my-company.io/"

Output:

➤ YN0000: ┌ Resolution step
➤ YN0001: │ HTTPError: @my-company/package@npm:^0.1.2: Response code 403 (Forbidden)
    at EventEmitter.<anonymous> (/path/to/.yarn/releases/yarn-berry.js:24:323118)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:94:5)
➤ YN0000: └ Completed in 0.41s
➤ YN0000: Failed with errors in 0.41s

But if i place the same npmAuthToken in the global scope everything works correctly.

[arcanis]

Does it work if the //npm.my-company.io/ is changed into https://npm.my-company.io/?

[gdorsi]

Nope

[deini]

@gdorsi Does it work if you remove the trailing / on npmRegistries?

npmRegistries:
  //npm.my-company.io:
    npmAlwaysAuth: true
    npmAuthToken: <token>
...

[gdorsi]

Removing the trailing / solved the issue!

Thanks :)

[bengry]

@deini I saw you marked this with "can't repro" tag. If needed, can you share with me (in private somehow) a case where this works? Alternatively, I can give you temporary access to a private scope in the npmjs.org registry, where I'm facing this issue. This will be for a limited time though, so we'd need to coordinate this. I'm not sure what other information I can give to help troubleshoot this.

[deini]

@bengry I tried to repro with a local instance of Verdaccio and a private instance of Bintray. Can you join our Discord Server? We can try to debug it together.

[bengry]

After debugging things around with @deini (thanks again! 👏) it turns out the auth token I used in the global .yarnrc.yml was invalid, even though it seems like existing Yarn v1 installs still respect it (or rather, npmjs.org).. Not sure exactly what's going on there, but generating a new token solved this.

I'm closing the issue since this seems to have been an error on my side.