To be honest, NPM is a complete shitshow when it comes to this, and I wish each and every single person who had a hand in developing it have their keyboards taken away, and never be allowed to touch any developer tooling ever again.

See this Stackoverflow thread:

https://stackoverflow.com/questions/45022048/why-does-npm-in...

The top answer has 3 updates to it, and links to 2 github issues, with conflicting information.

One says:

>If you run npm i against that package.json and package-lock.json, the latter will never be updated, even if the package.json would be happy with newer versions.

The other says:

>The module tree described by the package lock is reproduced. This means reproducing the structure described in the file, using the specific files referenced in "resolved" if available, falling back to normal package resolution using "version" if one isn't.

>This holds no longer true since npm 5.1.0, because now the generated module tree is a combined result of both package.json and package-lock.json. (Example: package.json specifies some package with version ^1.1.0; package-lock.json had locked it with version 1.1.4; but actually, the package is already available with version 1.1.9. In this case npm i resolves the package to 1.1.9 and overwrites the lockfile accordingly, hence ignoring the information in the lock file.)

So good luck figuring out what is true, but it seems to also depend on your version of NPM. Also, don't get me started on the presence of an entirely separate command "npm ci", which is supposed to be the one that is reproducible.

Absolute clowns.

Figuring out what is true for npm v5 is quite the waste of time, given that we are currently at v11. And that's what this ancient stackoverflow thread is about. npm certainly has a troubled past, otherwise we wouldn't have yarn and pnpm and whatnot. But _today_, npm install works very reasonably with lockfiles.