While the title of the page says "NPM lockfiles", the article actually talks about yarn lockfiles. In essence though, it applies to all lockfiles. An easy step for many organizations (especially with github actions) is to have it verified.
Perhaps you're misunderstanding what this article about.
The author is making a pr that updates the package.json, which also means the lockfile is updated.
If you don't accept any PR that touches the package.json file, then that means you're not accepting a PR that introduces any new dependency, tries to update a dependency for security reasons, or uses a feature available in a newer version of the dependency.
All of those reasons seem like valid reasons to accept a lockfile change -- that the author of the PR changed the package.json file for any of those reasons.
That's fine. Normally when I get a PR to update dependencies, I go ahead and update them myself, thank the submitter, and close the PR. No need to merge it directly. Similarly, if it adds a new dependency, I can ask them to put that in an isolated commit, cherry pick all the other commits, and update the dependencies myself.
No, I would likely not accept a PR that adds a new dependency. We try to minimize dependencies as much as possible, if the feature absolutely needed the dependency, we probably wouldn't open it for third party contributions in the first place (not least of all because maintenance of the dep now falls onto us if ever upstream falls short).
As for updating dependencies for security/features, we leave that to dependebot.
But since the lockfile can be generated from the package.json, I still don't see a reason that the lockfile needs to be committed by a third-party contributor instead of being generated automatically post-merge, or by the repository maintainers during the course of normal development.
If you use the lockfile like that then there is little point in having a lockfile. The lockfile specifies the exact versions of the whole dependency tree, and their hashes, at a given point in time. If you don't commit it then everyone will have different versions of the dependencies.
I see your point, but if a dependency package needs exact versions for its dependencies, I'd expect it to be specified in its package.json as well. If not, then I don't see why exact dependencies for the entire tree are needed.
Sure, if a package absolutely needs exact dependencies for its entire tree, it can check in the lock file, but I've not found this necessary in practice provided I use dependencies I trust , that follow semantic versioning.
> Sure, if a package absolutely needs exact dependencies for its entire tree
Not sure you're talking about the same thing as everyone else.
There's a big difference if you're maintaining a package vs maintaining an app.
If you're a "package" maintainer, you don't want to pin dependencies. Because the package consumer (i.e. people building apps using your package) should not have their exact versions dictated to them.
If you're an "app" maintainer, you absolutely need to check in your lockfile, because you should care about repeatable builds.
