Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] npm ci succeeds when package-lock.json doesn't match package.json #2701

Closed
icatalina opened this issue Feb 15, 2021 · 50 comments
Closed
Assignees
Labels
Bug thing that needs fixing Priority 1 high priority issue Release 7.x work is associated with a specific npm 7 release

Comments

@icatalina
Copy link

Current Behavior:

npm ci does not fail when package.json doesn't match package-lock.json

Expected Behavior:

npm ci refuses to install when the lock file is invalid.

Steps To Reproduce:

  1. Manually bump a major version of a dependency in package.json
  2. Run npm ci
  3. It should fail but performs the whole installation

npm@7

image

npm@6

image

Environment:

  • OS: Mac OS
  • Node: 14.15.3
  • npm: 7.5.4
@icatalina icatalina added Bug thing that needs fixing Needs Triage needs review for next steps Release 7.x work is associated with a specific npm 7 release labels Feb 15, 2021
@ext
Copy link

ext commented Feb 20, 2021

I've ran into this as well, is there any workarounds until this issue is resolved? Perhaps a flag or a new command could be added to verify the two files are in sync.

A consequence of this is that CI builds (which uses npm ci) now passes (as it installs an old version) even if a dependency would normally cause a build failure (such as when a major version as suggested by OP).

@wraithgar wraithgar added Priority 1 high priority issue and removed Needs Triage needs review for next steps labels Mar 26, 2021
@aaronadamsCA
Copy link

This is also affecting workspaces.

We are trying to switch from Yarn workspaces to NPM workspaces, and we were confused why npm ci would tolerate an outdated lockfile (whereas yarn install --immutable would error out). This bug seems to explain it.

This is more or less a blocker for switching back to NPM. The NPM CLI tools for managing workspace dependencies are still rough enough that I expect some mistakes; but without this bugfix, I don't know any other way to protect our main branch against a lockfile mismatch. 😕

@RA80533
Copy link
Contributor

RA80533 commented Jun 23, 2021

I see this happen quite often when the version field in package.json is bumped without making a corresponding change to package-lock.json, resulting in the files being out of sync.

@iggyzap
Copy link

iggyzap commented Jul 14, 2021

This bug contradicts description from documentation on how npm ci should work:

In short, the main differences between using npm install and npm ci are:

The project must have an existing package-lock.json or npm-shrinkwrap.json.
If dependencies in the package lock do not match those in package.json, npm ci will exit with an error, instead of updating the package lock.
npm ci can only install entire projects at a time: individual dependencies cannot be added with this command.
If a node_modules is already present, it will be automatically removed before npm ci begins its install.
It will never write to package.json or any of the package-locks: installs are essentially frozen.

https://docs.npmjs.com/cli/v7/commands/npm-ci

@legopin
Copy link

legopin commented Oct 4, 2021

@darcyclarke
This has been on P1 for a while, is there anything we can do to help move it along?

@mrmckeb
Copy link

mrmckeb commented Oct 8, 2021

We just hit this too @darcyclarke, as we're moving more repos to npm@7. I can confirm that there are no errors in the CI.

@sebastian-fredriksson-bernholtz

I just came across this and I'm shocked. In my tests, package-lock.json is completely disregarded and npm ci seems to act just like npm i, except it doesn't update the package-lock.json, so you don't even realise that a different version has been installed. What's the point of having package-lock.json then?

npm ci now seems like at least as dangerous an operation in CI/CD as npm i. It seems like the only use case for the command is no longer fulfilled. But maybe it does indeed work sometimes, as some people have indicated.

@patcon
Copy link

patcon commented Jan 12, 2022

Yeesh, this bug. Haven't tested it, but this might help for CI in the meantime: https://github.com/RocketChat/package-lock-check

@icatalina
Copy link
Author

It is sort of ridiculous that a Priority 1 bug has been opened for almost a year now... 😔

@ruyadorno ruyadorno self-assigned this Feb 1, 2022
ruyadorno added a commit to ruyadorno/cli that referenced this issue Feb 3, 2022
Make sure to validate any lock file (either package-lock.json or
npm-shrinkwrap.json) against the current install. This will properly
throw an error in case any of the dependencies being installed don't
match the dependencies that are currently listed in the lock file.

Fixes: npm#2701
ruyadorno added a commit to ruyadorno/cli that referenced this issue Feb 3, 2022
Make sure to validate any lock file (either package-lock.json or
npm-shrinkwrap.json) against the current install. This will properly
throw an error in case any of the dependencies being installed don't
match the dependencies that are currently listed in the lock file.

Fixes: npm#2701
ruyadorno added a commit to ruyadorno/cli that referenced this issue Feb 3, 2022
Make sure to validate any lock file (either package-lock.json or
npm-shrinkwrap.json) against the current install. This will properly
throw an error in case any of the dependencies being installed don't
match the dependencies that are currently listed in the lock file.

Fixes: npm#2701
Fixes: npm#3947
@ricardobeat
Copy link

Can anyone provide more context on what just happened here? The ci command was introduced as

npm ci bypasses a package’s package.json to install modules from a package’s lockfile

If ci installs directly from a lockfile, why is the extra validation step in 457e0ae necessary?

@ljharb
Copy link
Contributor

ljharb commented Apr 7, 2022

@ricardobeat the lockfile is only reliable if it satisfies the package.json; it's a bug that that validation was ever omitted imo.

@aaronadamsCA
Copy link

The docs have always been clear too:

If dependencies in the package lock do not match those in package.json, npm ci will exit with an error, instead of updating the package lock.

@ckirbybigdog
Copy link

ckirbybigdog commented Apr 8, 2022 via email

@dominykas
Copy link

dominykas commented Apr 8, 2022

This was meant to be fixed in 8.4.1, if I'm following the tags correctly, but I can still npm ci and it will happily install things even if package.json disagrees? Can someone please confirm this?

I'm also wondering about the correct behavior with deep dependencies - should there be a failure if the shrinkwrap overrides what's in their parent's package.json?

@patcon
Copy link

patcon commented Apr 25, 2022

Maybe of interest to others here, re: npm ci failure modes: (malformed integrity hashes ignored) #4460 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug thing that needs fixing Priority 1 high priority issue Release 7.x work is associated with a specific npm 7 release
Projects
None yet
Development

No branches or pull requests