It’s just security theater in the end. You can just as easily put all that stuff in the package files since a package is installed to run code. You have that code then do all the sketchy stuff.
What’s needed is an entitlements system so a package you install doesn’t do runtime stuff like install crypto mining software. Even then…
A package, especially a javascript package, is not necessarily installed to run code, at least not on the machine installing the package. Many packages will only be run in the browser, which is already a fairly safe environment compared to running directly on the machine like lifecycle scripts would.
So preventing lifecycle scripts certainly limits the number of packages that could be exploited to get access to the installing machine. It's common for javascript apps to have hundreds of dependencies, but only a handful of them will ever actually run as code on the machine that installed them.
True… I do a lot of server or universal code. But don’t trust browser code either. Could be connecting to MetaMask and stealing crypto, running mining software, or injecting ads.
And with node you get files and the ability run arbitrary code on arbitrary processes.
I would expect to be able to download a package and then inspect the code before I decide to import/run any of the package files. But npm by default will run arbitrary code in the package before developers have a chance to inspect it, which can be very surprising and dangerous.
PHP composer does the same, in config.allow-plugins.<package> in composer.json. The default behavior is to prompt, with an "always" option to add the entry to composer.json. It's baffling that npm and yarn just let the scripts run with nary a peep.
Finally sane solution. When I was thinking about package manager design, I also thought that there should be no scripts, the package manager should just download files and that's all.
https://github.com/orgs/pnpm/discussions/8945