Better yet don’t accept third party contributions to lockfiles... I don’t know any reason I would approve an external PR that modifies the lockfile.
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.
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.
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.
As for updating dependencies for security/features, we leave that to dependebot.