3 ms·
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 t
by 2trill2spill 8y ago
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.
- ilaksh 8y agohttps://docs.npmjs.com/files/package-locks https://docs.npmjs.com/files/package-locks has been the default for awhile. Are you using a pretty old version?
- LoSboccacc 8y ago> 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.
- frankwallis 8y agoThis 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.
- 2trill2spill 8y agoI'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? [1]: https://stackoverflow.com/questions/45022048/why-does-npm-install-rewrite-package-lock-json https://stackoverflow.com/questions/45022048/why-does-npm-in...