npm install - --registry parameter not respected

[leepowelldev]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

I have created this repository to demo the issue:
https://github.com/leepowelldev/npm-registry-issue

The scenario is a developer is working on an internal network with a local, non-public registry. They install the popular rimraf package from via local registry, and then deploy to the cloud to build and deploy. Their cloud pipeline task is setup to use the public npm registry.

npm install --registry="https://registry.npmjs.org"

However the install fails as npm keeps trying to access the packages from the internal registry, even though an alternative one was specified.

This works as expected when using npm v6, however fails when using npm v7.

Expected Behavior

npm should transparently use the specific registry as v6 did

Steps To Reproduce

Instructions in repo README

Environment

• OS: OS X
• Node: 14
• npm: 7

[wraithgar]

The registry setting will only inform npm where to pull packages via name. Once the package-lock is made, that is where things will be pulled from. If you want them to be different you will need to bypass the package-lock.

[leepowelldev]

@wraithgar Ok. Although this is frustrating as v6 did not work in this way and there was no documentation of this rather major change in the v7 release notes.

[ljharb]

@wraithgar thst does seem like a bug; my understanding is that npm is supposed to ignore the URLs in the lockfile and defer entirely to the registry settings in config.

[josh18]

Can someone confirm if this is intended or a bug?

We are transitioning some of our software so currently our CI process installs from a different registry than developers for a specific scope. It seems like the the only way to resolve this case is to ignore the package-lock or find / replace the registry in the package-lock, is that right?

[leepowelldev]

@wraithgar - as this has been reopened, are we acknowleding this is an issue?

[wraithgar]

I don't know. I opened it because it is something people are still confused about one way or the other and it needs to be in our backlog to investigate.

[leepowelldev]

I think people are confused because it does not work in the same way as v6. Which is fine if the mechanics have changed, but would need to be documented.

[ddolcimascolo]

We've just been hit by this. This completely block our continuous deployment for a use case that I'm sure is not uncommon:

• We use a private npm registry as a cache to speed up developper installs and builds (verdaccio). This registry is not accessible to production environments network-wise
• Lockfiles contain resolved URLs pointing to the private registry
• Production installs during deployments use --registry=https://registry.npmjs.org/ to download packages from Internet while still respecting the lockfile

We rolled out Node 16 (so also npm@8) yesterday just to discover this.

This important breaking change can only be noticed by comparing documentation pages between npm@6 and npm@8 (https://docs.npmjs.com/cli/v6/using-npm/registry vs. https://docs.npmjs.com/cli/v8/using-npm/registry)

Also there's no workaround given.

Can you either

• Revert this change
• Explain the rationale behind it and give us a workaround

Thanks.

Regards,
David

[leepowelldev]

We worked around this in the end by using this package in our CI build to modify the lock file without having to delete/recreate it. Not ideal but it works. https://www.npmjs.com/package/lock-treatment-tool

[ddolcimascolo]

Yep, I just sed my lockfile for the same result