> If npm respected every upstream lockfile, then it could never share a single version that satisfied all dependencies.

I'm asking in the context of installing a single CLI tool into ~/bin or something. There's no requirement to satisfy all dependencies, because the only dependency I care about is that one CLI tool. All I want is an equivalent of what `cargo install --locked` does — use the top-level lockfile of the CLI tool itself.

That sounds pretty reasonable: npm should allow bundling the lockfile with things that are marked with the type of "project", and whether it actually uses them depending on whether other locked constraints are overriding it. So instead of one lockfile, a prioritized list of them. The UX of dealing with that list could be a sticky wicket though, and npm isn't known for making this stuff easy to begin with.

npm itself does not know that what you are installing is a CLI tool.

Good CLI tools are bundled before release so they are zero-dependency as far as npm is concerned, which is ideal imho for all CLI tools, but many don't do that.

Looking for "type": "project" is about as close as npm gets to knowing whether something is a command, but lots of libraries do ship with utility commands. npx knows, since it's used for nothing but commands. I've never seen bundling used for anything I've installed through npm; that's more likely for standalone downloads and possibly things like homebrew.

I'll repeat that the bigger problem is that npm has such unfettered access to everything in the user account to begin with. FSM knows it's not strictly an npm problem, it's a Unix problem that's been there since the beginning, just that now, enough of the chickens are coming home to roost that people are starting to notice.