As someotherguyy already mentioned, this is a default feature in pnpm.

And as far as cat-and-mouse-games go in other package managers, I'd say that pinning dependencies and disabling postinstall scripts is a much better option. Sure, not a foolproof one either, but as good as it gets.

edit: misspelled someotherguyy's user name

▲

buu700 an hour ago | parent | next [-]

I recently learned that this is (for all intents and purposes) a feature in npm as well, specifically the `--before` flag to `npm install`: https://docs.npmjs.com/cli/v11/commands/npm-install#before. That was harder than it should've been to figure out; it really needs better marketing.

Related to that is the proposal for `stabilityDays`, which seems way more practical: https://github.com/npm/cli/issues/8570#issuecomment-33004136.... So rather than merely saying "I only want package versions more than N days old", you'd be adding the requirement that "...and also they should have gone at least N days without a subsequent patch release". e.g. if mylib@6.0.0 is released, only to be quickly followed by 6.0.1 and 6.0.2, you ideally wouldn't want to risk ever installing the probably-broken 6.0.0 or 6.0.1 based on luck of the draw; the better behavior would be to stick with the last 5.x release until 6.0.2 has aged past the threshold.

▲

2muchcoffeeman 2 hours ago | parent | prev [-]

Why is the community persisting with such poor solutions?

	▲	moritzwarhier 2 hours ago \| parent [-]
		What would be a better solution? Do other package managers reliably restrict access to the host system beyond the scope of the project folder? Many quirks come from abilities that were once deemed useful, such as compiling code in other languages after package install. Sure, today, I can disable install scripts if I want but it doesn't change much when I eventually run code from the package anyway. But even restricting access to the file system to the project's root folder would leave many doors open, with or without foreign languages: Node is designed as a general purpose JS runtime, including server-side and build-time usage. The utility of node.js was initially to provide a JS API that, unlike the web platform, is not sandboxed. And npm is the default package manager. This not only allows server-side usage, but also is essential to many early dev scenarios. Back in the days, it might have been SCSS builds using node-gyp (wouldn't recommend). Today it's things like Golang TypeScript or SSGs. So, long story short: as many people before me already said, it's an ecosystem/cultural problem. One thing against npm in this regard was/is its broken lock-file handling until I think version 12 or 16. That led to unintended transitive dependency version changes, breaking any reproducibility. Same for compiling foreign languages. These problems are solved today / not different from other package managers and -registries, as far as I know. The culture of taking breaking changes and dependency bloat lightly has not changed as much, I think, although it's improved. This most important point seems to be related to 3 reasons IMO: - junior developers without experience in library development reaching large audiences - specs, languages, runtime, and the package managers itself going through disruptions and evolutions - rapidly releasing breaking majors, often caused by the above factors The combination of these plus the role of the project lead/team who actually decides about the dependencies. There are probably also many projects with unclear roles and many people who can push manifest changes, coupled with habitual access to CI/CD pipelines.