We're getting into minutiae here. Yes npm install will update the lock file if package.json conflicts. But it certainly does not update every time npm install is run if you use a lock file, which is what your earlier comment (and those of others) mistakenly imply.
If you have ~1.0.0 in package.json and 1.0.11 specified in the lock file, but then bump package.json to ~1.0.12, yes npm will upgrade the package and then bump the dep in your lock file to 1.0.12. That seems fine?
This is not my experience with how most people specify their dependencies (and the tools use by default)
If you have `^1.0.0` in package.json, the version mark is `^1.0.11` in the lock file, which means that a random `npm i` or `yarn install` will install `^1.0.12` in your lock file.
I more or less said this yesterday[1], but the behaviour of `yarn install --frozen-lockfile` and `npm ci` should be the _default_ behaviour. The current behaviour is demonstrably dangerous. A lockfile should remain locked without explicit action by developers.
"If you have `^1.0.0` in package.json, the version mark is `^1.0.11` in the lock file, which means that a random `npm i` or `yarn install` will install `^1.0.12` in your lock file."
That's not true. package-lock.json file dependencies are specified as exact versions, not ranges. If you have 1.0.11 in your lock file, npm install will always install 1.0.11 unless it no longer satisfies the version in package.json.
“The presence of a package lock changes the installation behavior such that:
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.
The tree is walked and any missing dependencies are installed in the usual fashion.”
The scenario is a _little_ more complicated than I laid out, but I have seen this in practice. I _believe_ that it will happen when you have two copies of a repo and one of the copies does not have one of the dependencies. If user A (repo copy 1) adds a package with `^1.0.0` but the lockfile indicates `^1.0.11`, then user B (repo copy 2) will get `^1.0.12`.
The _only_ correct behaviour for a lockfile is `=1.0.11` (I think that npm calls that `1.0.11`, but NPM’s semver specification is unnecessarily complex compared to Elixir or Ruby) unless there is an explicit update. Otherwise, you will _not_ get the same version installed for all developers.
"If user A (repo copy 1) adds a package with `^1.0.0` but the lockfile indicates `^1.0.11`"
NPM lockfiles can't indicate `^1.0.11` so I believe this is where you're mistaken. They point to a specific version (`=1.0.11`) just like you're saying they should.
No, that is madness. A new developer clones the repo and gets wildly different dependency versions than the previous devs tested with. Then once you PR your changes, you include that lockfile and production explodes. Insane. And yes, this is a real problem. See the thread we're posting in and how many projects it affected.
“A new developer clones the repo and gets wildly different dependency versions than the previous devs tested with.”
Could you describe a scenario where you think this happens? It doesn’t if you have a lock file in version control. Do you mean if it’s not in version control?
