When Not to Use Lock Files with Node.js

Re:When Not to Use Lock Files with Node.js by smartinspereira on Sunday March 15, 2020 @05:30PM (#22586949)

This sounds more like a fix for an issue that should not exist in the first place. Why is npm ignoring the lock file to begin with? Why not publish and respect it on install?

[ Parent | on HN ]

Re:When Not to Use Lock Files with Node.js by syspec on Sunday March 15, 2020 @05:37PM (#22587030)

It can blow up your bundle size if everyone has patch version mismatch . That's probably the only reason I can think of.

In theory semver should help with this, but humans decide the semver version and it's not always possible to know the effects of a change so they may mark it as patch, but it breaks something and you get this sceanrion

[ Parent | on HN ]

Re:When Not to Use Lock Files with Node.js by paulddraper on Sunday March 15, 2020 @05:50PM (#22587130)

It's a consequence of modularization, and it's not at all unique to Node.js. (Although Node.js has hyper-modularization, so the situation is more pronounced.)

Ruby gem has lock files, Python pip has lock files. I wish everyday that apt/dpkg had lock files.

The balance is between permissive versions (small install size) and pinned versions (reproducibility).

Some situations call for one, some call for the other.

[ Parent | on HN ]

Re:When Not to Use Lock Files with Node.js by j88439h84 on Monday March 16, 2020 @03:38AM (#22590791)

But doesn't Node give each module its own deps? Python can't do this because it doesn't support multiple versions of the same dep.

[ Parent | on HN ]

Re:When Not to Use Lock Files with Node.js by ailideex on Sunday March 15, 2020 @05:33PM (#22586980)

If your package only works with specific versions you should put those versions in package.json - if the versions in package.json is correct then what specific versions within those bounds someone uses is ... well ... unrelated to your package.

[ Parent | on HN ]