Your own link says that a proper package manager (e.g. pnpm) supports this out of the box.

If there are other use cases that really need post-install scripts, you can whitelist just those in pnpm. In projects I'm working with, there are often zero post-install scripts that must be enabled for everything to work properly, and it's usually from poorly cobbled packages that use them to download prebuilt binaries (well written packages, like biome or tsgo, use per-architecture subpackages).

You enable just one or two of those, and block everything else.

How would getting rid of postinstall break patch-package? If people use a package, and that package needs some kind of step to get working, user of that package should decide when that step happens. He can very well just call patch before building on his own. There's zero issues with that approach and the upside is he actually has control.

I work in a monorepo where running install calls dozens of deeply nested postinstalls of some elaborate NextJs or React Native dependencies other projects use. It's borderline insane. Unless you regularly screen everything, it's impossible to know whether one of those is compromised, especially in the world of Node where is-even is being used and the sheer amount of crypto scams around.

The entire use-case of that package is a security nightmare.

Given that has an impact over the whole industry, I will for sure tell you that patching on install SHOULD NOT be a thing. Up to you to run your own post install script yourself

Elaborate on the "behave properly". What is properly here?

Or maybe just add a script in package.json to run whatever patch-package does (eg, "install:patch": "npm install && patch-package") instead of whitelisting every package to have that power.

You’re free to allow scripts as per the linked docs for NPM 12. But the vast majority of us will appreciate the reduced attack surface.

TFA explains how this works, and how to opt out.