The lock file records the hash of each package and uses it to verify package integrity on future installs. If any of the hashes don't match up, the `npm clean-install` command[0] will throw an error.
The NPM ecosystem commonly uses these types of specifiers. Even if your own dependencies are all specified in “package.json” using exact versions, they almost certainly depend themselves on other versions (dependencies of dependencies, and so on) using the semver specifiers. That means whenever an author of that package publishes themselves, your resolved dependencies may change.
The package-lock.json is simply a record of the exact dependency resolution graph based on the registry state that existed at the moment you generated it, so that you can reliably reproduce that graph a month or a year later. Otherwise it’s very common for NPM-based projects to have “NPM install” fail later on (or succeed, but create a bug or unit test failure) because some new version was added to the registry and created a compatibility issue or bug.
But package-lock is intended to be used at the project level. i.e. lock all package versions in the current project or app.
That isn't "useless in most cases", it solves specifically the case it is meant to solve.
> It’s even more useless if you think that production apps are built very often as tagged docker images = are reproducible by design.
But you're stuffed if you need to rebuild the docker image later, or for example, go back to an old commit/release, create a 'support' branch to retrofit a change and build a new image. You want repeatability all the way down.
No, a much more useful use case is avoid breakage from minor version updates in your 15th level dependencies. You might be cognizant of your semver best practices, but the team who publishes the string utility library included by the query builder included by your ORM might not be so careful.
I think you mean "Yes, but also ..."
They didn't say "only", they said "things like".
1. Ultimately dependencies end up in your production environment, so folks might wanna review the diff of dependency updates.
2. No need to run yarn install. So if your build server has only access to your git repo, no need to get packages from a remote environment.
3. No need for yarn or npm on non-Frontend dev machines. It will just work with Node installed.
4. If npm or yarn ever cease to exist (or the registries), any commit should still work as intended.
So if that part of the infrastructure is down, you cannot work. A repo might be more error resilient, because if you check it out, you check it out.
Edit: a minor version update should not be backwards incompatible and break things. If it does, the package is poorly maintained imo.
You can pick your poison.
Each one of those exact versioned libraries you referenced will itself likely have semantic version dependencies which may update themselves. Unless every single dependency you depend on also follows the policy of pinning to exact versions (and their dependencies do the same, and so on), you are still vulnerable (See left-pad incident, which was a sub-dependency of babel).
The only way to avoid this is the old shrinkwrap or the new package-lock.json feature.
I always set up an ignore rule for them and use package.json's dependency list instead. My projects are all on the small side though; is the idea to commit the .lock file and avoid breakage through things like minor version updates of your first level dependencies? Wouldn't that carry a bigger security risk for large numbers of packages that then aren't receiving patch updates as readily?