[RRFC] Run preinstall / postinstall scripts on single package installation

[karlhorky]

Hi there, first of all, thanks for all of the hard work on npm and everything surrounding it! Really cool what you are doing.

Motivation ("The Why")

The behavior of npm to not run preinstall or postinstall scripts specified by the developer in the project on every npm install <pkg name> is confusing and leads to support requests such as npm/cli#1732

Would you consider starting to run these scripts once during installation of a package?

Example

npm install node-fetch # would also run the `postinstall` script

How

Current Behaviour

preinstall and postinstall scripts are not run during npm install <pkg>

Desired Behaviour

the scripts are run

References

• Originally a Discussion in npm/feedback: Run preinstall / postinstall scripts on single package installation feedback#217, and @MylesBorins mentioned I should make an RFC here

My original use case was to be able to also install the corresponding @types/<pkg name> DefinitelyTyped dep (à la #328). See here for my original naïve approach (which ended up failing): https://github.com/jeffijoe/typesync/pull/65/files

---

Alternatives Considered

Hook Scripts

In the Open RFC Meeting on Feb 17, 2021 @darcyclarke and others mentioned Hook Scripts.

There are two downsides I've run into so far:

1. they seem to be broken in npm v7 [BUG] Hook Scripts Not Run on npm install cli#2692
2. in npm v6, a postinstall hook script, for example, runs once for every package that has been installed. So this means that with a node_modules/.hooks/postinstall script, if you run npm install with your package.json containing 20 dependencies, this script will run at least 20 times, and even more if those dependencies specify transitive dependencies...

[karlhorky]

Thanks for the responses during the Open RFC Meeting on Feb 17, 2021! Interesting to hear a bit of the background.

I added "Hook Scripts" to a new section above called "Alternatives Considered", along with documenting the roadblocks that I ran into there.

Clarifying the current behavior with docs and separating out the use cases for any future features sounds like good next steps, thanks! 👍

cc @isaacs @wraithgar @darcyclarke @ljharb

[karlhorky]

Thanks again for the responses during the Open RFC Meeting on Feb 24, 2021!

Sorry for not being able to join again! The timing is kind of difficult for me - maybe I'll be able to join at some point.

A few comments:

@isaacs mixing the semantics of existing preinstall and postinstall and this new proposal of "General-purpose tree-install-has-changed script" is probably not good

@ljharb it should run only for the top-level project and not for any project installing a package that has this lifecycle event

I see what you mean, that makes sense. Right, well if new types of scripts are preferable to keep backwards-compatibility and the existing semantics, then I don't see anything speaking against this. Seems good! 👍

@ljharb might be better to think about from a more user-friendly point of view [instead of using the arborist reify terminology]

Right, if there would be bikeshedding on the name (probably far down the line still), I would also suggest avoiding surfacing these internal technical terms, if possible. Simple, commonly-understandable naming will make searching for and remembering these hooks easier.

[karlhorky]

Thanks also for the responses during the Open RFC Meeting on Feb 24, 2021!

@isaacs we need a "install tree has been mutated" lifecycle script, that would solve this without conflatig what preinstall/postinstall are used for.

@darcyclarke let's backlog writing an actual RFC for that

Right, this feels like a logical extension of the results of the previous meeting, thanks!

use cases

Just as a quick note about this here (I've also added this to the description above), my original use case was to be able to also install the corresponding @types/<pkg name> DefinitelyTyped dep, à la #328 . See here for my original naïve approach (which ended up failing): https://github.com/jeffijoe/typesync/pull/65/files

[CalculonPrime]

I'm curious. Was there any polling of npm users done prior to rolling out this new policy of whether they thought suppressing all install script input/output for all modules was a good idea, just to stop a few bad actors from showing ads when their modules get installed?

I'm puzzled by how you can trust someone to run code as a dependency, but not trust them to print responsibly during install. Don't add dependencies you haven't vetted. Then there is no concern.

[Apollon77]

@wraithgar closed some issues with reference here where it was about "install" script no longer running. WHen I read here - especially the initial post - this isue is mainly on postinstall/preinstall ... or is install considered too?

Our usecase is that we do some "data housekeeping and corrections" and also user-convenience things in install script and it was executed on any install/update so far. So what's considered as the alternative?

Any yes: I would expect more good behaviour by developers then bad