It won't protect against a newer version of an established library introducing malicious behaviour.

This is correct, the few dependencies you would use would need to also target very specific versions to achieve the same.

Lock files are used to lock dependency versions all the way down your dependency tree, not just your immediate dependencies.

Unfortunately this seems to be the case; lockfiles would be unnecessary only if all your dependencies (and their dependencies, recursively all the way down) reference explicit versions, the risk being that a new malicious version would be published. I'll research if there's a workaround.

Thanks everyone for pointing out this issue.

In my opinion a lock file really is the "work around", I don't see a huge issue in using them since it's given for free by npm and yarn with no additional overhead.

You can specify exact versions, but your deps might wildcard with "~" or "^" or they might specify a range of versions. Thus, a new dep of a dep might be installed the next time you update.

I wonder whether one of the npm alternatives has a "--sane" mode that would always pick the oldest possible dep...

Why the oldest possible?

Thread hypothesis is that we want to avoid breakage due to automatic dependency updates. So, don't update dependencies automatically. Now sure, if you tell the tool to update a particular dep, it will force second- and higher-order deps to update to compatible versions. It will always use the oldest compatible version, so nothing will get broken in surprising fashion. This seems strange to people who've used mostly npm and node, but tools for other languages have this policy.

I see. I've never heard of that before, thanks for sharing!