Adding a scoped package under a custom alias that does not include the scope fails to send auth headers.

[austin-rausch]

Bug description

Yarn install for a custom aliased package that is private and scoped does not send auth headers. When adding the scope to the alias name, or include always_auth it will send auth headers.
Command

yarn install

What is the current behavior?

When trying to install a scoped private package as an alias without the scope, yarn install is not sending auth headers causing a 404 on install.

What is the expected behavior?

The install should not 404, and instead should send auth headers along with the request.

The npm registry should not use the package name for an aliased package, it should use the target package, E.G.
"some-alias": "npm:@some-scope/some-package@1.0.0",
Should use @some-scope/some-package not some-alias
See:

yarn/src/registries/npm-registry.js

Line 157 in b07a19b

if (this.token || (isToRegistry && (alwaysAuth || this.isScopedPackage(packageIdent)))) {

Steps to Reproduce

1. Add an aliased package at an alias name that does not have the scope, E.G.yarn add some-alias@npm:@some-scope/some-package@1.0.0 that has a scope and requires authorization
2. Attempt to yarn install
3. Receive 404 error

Environment

• Node Version: 12.14.0
• Yarn v1 Version: 1.2.1
• OS and version: macOS High Sierra version 10.13.6

[alexk111]

Here is a workaround for the issue: #8130 (comment)

[laggage]

I encountered the problem too, It bothers me a lot. Does anyone have any temporary solution for it?

[austin-rausch]

@laggage

If you make the alias have a scope it will send the authentication header, E.G.

"@some-scope/some-package_1_0_0": "npm:@some-scope/some-package@1.0.0",

Since the alias name / key name / package identity (which is the part that gets used for the isScopedPackage) has the scope it will send the auth headers.

The work around linked above is strange, to depend on the cache for the install, and since the linked issue above is closed as its fixed in v2 this seems to be the path forward. Can't say I agree with closing the linked issue.

[gamedevsam]

There's plenty of people sill using yarn@1.x - this should be fixed imo. Just ran into this issue and spent half a day trying to figure out what was causing it.