[BUG] aliases don't work with scoped packages in private registries

[kevitan]

Is there an existing issue for this?

• [X] I have searched the existing issues

This issue exists in the latest npm version

• [X] I am using the latest npm

Current Behavior

Related to #2884 : Unfortunately I don't remember what workaround I used last time, but it appears I've run into the same issue, both on NPM 8.19 and NPM 9.4.

in package.json, I have:

"dependencies": {
  "aliased": "npm:@scope/my-package@^1.0.1"
}

and when I run npm i, I still am getting a 404

npm ERR! code E404
npm ERR! 404 Not Found - GET https://my.scope.registry.io/@scope/my-package 1.0.1.tgz
npm ERR! 404
npm ERR! 404  'aliased@https://my.scope.registry.io/@scope/my-package-1.0.1.tgz' is not in this registry.
npm ERR! 404
npm ERR! 404 Note that you can also install from a
npm ERR! 404 tarball, folder, http url, or git url.

strangely enough, if I remove the aliased reference in the package.json it installs with no issue. Then, if I then put the alias back into the package.json, there no longer is an error when I run npm install (or npm ci)

Expected Behavior

npm install can resolve the alias and the scope in the private registry

Steps To Reproduce

.npmrc:

@scope:registry=https://my.scope.registry.io/
//my.scope.registry.io/:_authToken=<token>

rm -r node_modules

npm i

Environment

• npm: 9.4.0
• Node.js: 18.12.1
• OS Name: MacOS 12.6
• System Model Name: Macbook Pro

[kevitan]

if I add a non-aliased version to the list in addition to having an aliased entry in package.json, It succeeds on two successive NPM installs.

However, if I remove the non-aliased entry in package.json, it fails every time again after i clear the npm cache and delete node_modules

[kevitan]

We did find a workaround:

Our private registry is hosted in GitLab - our original login only logged into the package registry endpoint. by adding in the Project level repository, it worked:

@scope:registry=<GITLAB_NPM_REGISTRY_HOST>
//<GITLAB_NPM_REGISTRY_HOST>:_authToken=<API_TOKEN>
//<GITLAB_PROJECT_API>:_authToken=<API_TOKEN>

It feels like the way NPM is parsing the same scope differently in two cases, like an entry for

"some-package": "npm:@scope/[email protected]"

is parsed differently than

"@scope/private-package": "1.2.3"

where the former call needs metadata from GitLab from the project itself? I'm not sure why, though, since the packages are published to the Registry, which is a different API than the project one.

[fyhhub]

I have the same problem

[mhaidamashko]

Aliases don't work not only for scoped packages, in my situation it's a regular one.

[binhvo-hproptech]

I have had same problem

[Talhasaleem110]

@binhvo-hproptech

[drabelogarner]

Ran into this problem where we were trying to alias a private package. The issue turned out that we needed to make sure to prefix the alias with the private registry prefix, otherwise the pipelines were failing to install. ie. "@scope/alias_name": "npm:@scope/[email protected]"

[OSapozhnikov]

I have a similar issue. We need to fix it

[devops01ua]

hit the same

workaround works but it's should be fixed. Thx

[grigory-bogush]

We did find a workaround:

Our private registry is hosted in GitLab - our original login only logged into the package registry endpoint. by adding in the Project level repository, it worked:

@scope:registry=<GITLAB_NPM_REGISTRY_HOST>
//<GITLAB_NPM_REGISTRY_HOST>:_authToken=<API_TOKEN>
//<GITLAB_PROJECT_API>:_authToken=<API_TOKEN>

It feels like the way NPM is parsing the same scope differently in two cases, like an entry for

"some-package": "npm:@scope/[email protected]"

is parsed differently than

"@scope/private-package": "1.2.3"

where the former call needs metadata from GitLab from the project itself? I'm not sure why, though, since the packages are published to the Registry, which is a different API than the project one.

Same issue. Is there any workaround for github npm packages? These values seem to be gitlab specific or am I missing sonething?

[grigory-bogush]

Nevermind, I missed that the project actually used yarn during build. On npm 9.. it works fine