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

[ruyadorno]

This is expected behavior, the documentation expands a bit further on it in Configuring npm > package-lock.json:

resolved: The place where the package was actually resolved from. In the case of packages fetched from the registry, this will be a url to a tarball. In the case of git dependencies, this will be the full git url with commit sha. In the case of link dependencies, this will be the location of the link target. registry.npmjs.org is a magic value meaning "the currently configured registry".

The historical reason for the breaking change is trying to provide a more clear and safe usage of the resolved field while having deterministic installs from the lockfile.

These changes are part of our continuing efforts to improve the UX of lockfiles and we currently have some initiatives exploring better solutions, primarily the Resolved registry overrides RFC by @everett1992.

I'll close this issue as it seems it will not get much more traction and it's not an actual bug to fix but to anyone still interested in improving the usage of the resolved field of package-lock.json I'd recommend trying to chime in the current proposals in the RFC process or bring in new ideas on ways the cli could offer ways to work around this issue.

[tfbroner]

This issue should be re-opened, as it clearly is a BUG in the CLI. Command line parameters are the ultimate overrides, this is world standard in software. If the override can't be applied, or is invalid, the CLI has to throw an error to that effect, not ignore it.

FYI: I'm facing the same issue, where I use local Verdaccio and try to publish with:
npm publish --registry=http://localhost:4873
and it completely ignores this command line option.