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

[icatalina]

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

npm@6

Environment:

• OS: Mac OS
• Node: 14.15.3
• npm: 7.5.4

[ext]

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).

[aaronadamsCA]

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]

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]

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]

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

[mrmckeb]

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]

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

[icatalina]

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

[ricardobeat]

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]

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

[aaronadamsCA]

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]

Oh OK I apologize my bad

…

On Fri, Apr 8, 2022 at 4:56 AM Aaron Adams ***@***.***> wrote: 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. — Reply to this email directly, view it on GitHub <#2701 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AYQ6CPSOXPCA2C4TJP33RL3VEANGVANCNFSM4XT6MXKA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[dominykas]

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]

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