[RRFC] Development lifecycle scripts (hooks)

[ylemkimon]

Motivation ("The Why")

Sometimes in a project, there is a need to setup the development environment or enforce some policies on dependencies used in the project. However, npm doesn't provide a way to hook into its process and lifecycle scripts such as postinstall are (ab)used:

• husky uses postinstall to autoinstall Git hooks and pinst to disable them in the production
• postinstall-postinstall runs the app's postinstall script during its postinstall script
• TBA

Furthermore, there is no way to run a script if the dependency tree of the pakcage has changed, i.e., a dependency is added or removed.

Example

As mentioned above, it can be used to setup the development environment or enforce some policies on dependencies used in the project.

How

Current Behaviour

• postinstall script runs after npm install, but also runs when the package is installed as a dependency
• prepare script runs after npm install, but also before the pakcage is packed
• Both scripts don't run when the dependency tree is changed and there is no way to trigger a script in this case

Desired Behaviour

• A new lifecycle, such as preinstalldep and postinstalldep
• or, hook scripts that run before and after the dependency tree has changed (reify)

References

• Old RFC RFC for dependencies change script addition #34 exists but seems stalled
• Alternative to [RRFC] Run preinstall / postinstall scripts on single package installation #325
• Related to RFC: Robust Lifecycle Scripts #437

Other package managers

• Yarn 1: undocumented hooks can wrap each step (Adds an undocumented run hook yarnpkg/yarn#7557)
• Yarn 2: hooks can be added via a plugin (https://yarnpkg.com/advanced/plugin-tutorial#using-hooks)
• pnpm: hooks can be added via configuration (https://pnpm.io/pnpmfile)

[everett1992]

A post-reify script would be useful. We try to run a script to remove the resolved key from package-lock after any modifications because we build packages against different registries. We have some wrappers that 'know' which npm commands update the lock file, but if the wrapper is wrong or not used the lock file ends up in a dirty state. #486