At RunKit, we've actually installed every version of every package, and I can assure you that it is not the case that there's tons of packages using install scr

At RunKit, we've actually installed every version of every package, and I can assure you that it is not the case that there's tons of packages using install scripts for really great reasons. For starters, the vast majority of packages do not use this feature. Then, you have to consider that install scripts are a very old feature designed for a series of constraints that are either no longer representative of the state of the ecosystem, or quickly won't be. For example: 1. The most "legitimate" use of install scripts is to build binary node addons. N-API is a much better alternative with ABI compatibility that will allow the package to just ship built, which aside from being a much friendlier and faster install experience, will also allow for more deterministic builds and better caching. 2. Many install scripts just transpile code on installation. It would be much better to instead just transpile the code on publish. This is something that requires nothing new and everyone should absolutely just do today. It's crazy that people re-download and retranspile the same code over and over. 3. Many install scripts simply download non-npm resources, like apt dependencies or things like Chromium. It would be a lot better, a decade after npm's introduction, to standardize this common use case like this instead of having everyone roll their own. We actually implemented our own version of this where we can just list apt dependencies in our package.json. It gives you so many more options on how to optimize builds and provides you so much better information about your dependencies to have this be a "declarative" piece of the puzzle as opposed to having every package figure out their own slightly different way of doing this. 4. Many install scripts just present the user with ads. NPM should also just add a package.json field for donation links or whatever and provide a good standard way of disabling this as opposed to spinning up a process just to present ads. 5. And of course, some install scripts are used maliciously. All this to say, 10 years later, there aren't actually a bunch of "wow, what an interesting use of the install script" examples, but rather just a bunch of fairly limited common uses (that could be better handled by npm itself), and yes, some interesting stuff, but also a worrying amount of abuses, that are easily duplicated and that we are currently doing nothing to stop. Given a proper transitional period, where npm just warns you above an install script rather than failing, I think most packages could be made to not require custom install scripts. And again, this is for a small percentage of packages, nowhere near the undertaking of converting packages on NPM from CommonJS to ESM for example. And, it's not that it would be disallowed, it's just that the rare package that really did need to do something really out there would need a flag. Having actually queried all the packages, I am certain this could be done with basically no disruption for end users, certainly no disruption to most package authors that don't use these scripts, and almost no disruption for the few package authors that currently use this feature.