[moritzwarhier]

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]

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.

[moritzwarhier]

Thanks for sorting out the detailed info! While I use an alternative package manager at $job, I personally wish for npm to be a stable mainline for Node package management and to sherlock the advantages of pnpm, yarn etc.

[2muchcoffeeman]

Why is the community persisting with such poor solutions?

[moritzwarhier]

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.

[LelouBil]

Deno has capabilities, but I don't use it so I don't know if they are useful in practice or if everyone just always allows everything.

[m4rtink]

Established Linux distributions.

[moritzwarhier]

Sure. But I'm not sure if I wanted to burden their package registry maintainers with maintaining all kinds of JS/TS packages?

And if you go for custom registries, what's the big difference to npm registry?

I don't understand it :)

One good thing about npm ecosystem IMO is that it's frowned upon to depend on system globals.

[pianopatrick]

There are already quite a few JS / TS packages in the Debian repos. Some examples:

https://packages.debian.org/trixie/node-pg https://packages.debian.org/trixie/webpack https://packages.debian.org/trixie/eslint

So someone is already taking on that burden.

[m4rtink]

Maybe that's another indication of something wrong - the NPM ecosystem granularity being so high there is not enough humans alive to safely maintain all the packages ? And some rethinking might be needed even there.