Exactly, I deal with npm on a daily basis and I really wish deterministic builds were more of a concern in the javascript/npm universe. I can't count how many times a project broke because a "minor" release came out and broke existing code. Also the majority of projects have a caret in their package.json package versions so you automatically get the updates.
I'm well aware of package locks. However npm has a horrible implementation of package locking. Running npm install will regenerate your package lock unless you removed prefixs from all your packages or you install using --package-lock-only[1].
So my question to you is, have you been using npm package locks correctly? Or do you let npm install generate a new package lock every time its run?
> It is highly recommended you commit the generated package lock to source control
Fixed the Javascript way, layers of workarounds.
And if you indeed need to update a dependency, you need to regenerate the lock.
But the main difference is that when that happens, the onus to verify all packages transitive unpinned dependencies still result in a working combination (of which there is no guarantee) is on the receiving developer, not on the package maintainer.
This is untrue. If you need to update one dependency; npm/yarn will update the lockfile with the minimal changes needed to update that one dependency. You do not need to regenerate the entire lockfile.
