Separate lifecycle script contexts

[wraithgar]

In current package.json setups there is a "script" entry that has certain lifecycle events defined. These are things like "install" and "publish". The context for these is not very discrete. For example, if I have an "install" script defined in my package.json that will be run when I type npm install, but it will ALSO be ran when that same package is installed as a dependency.

Folks can currently disable all scripts, but this does not allow for the ones defined in my root package.json to still run. We need a way to separate "user/project" level context from "dependency" context.

A solution has been wanted for quite some time, and I think the interop group here is the right place to figure it out.

Consideration: the current "scripts" lifecycle, especially for packages being installed, is something that is quite possibly unable to ever change. It's been like this for too long.

[darcyclarke]

👋🏻 I'd notably be happy to work with you on this/across package managers. I do think that because npm & vlt both have an implementation of a query selector language makes us uniquely positioned to solve this problem holistically. I know in our case at least we've effectively made install a two-step process where "building" (ie. binary linking & script execution) happens after graph resolution - making it possible to use query selectors as a mechanism to filter what dependencies actually run scripts (ref. https://blog.vlt.sh/blog/vlt-build). We've actually applied this concept broadly to all our other commands - including script execution (ref. https://blog.vlt.sh/blog/run-exec-query-support). This means any script execution (ie. vlt run or our alias vlr) actually has the ability to filter on the widest variety of known contexts/metadata.

Examples

vlt install
# the default value of `--allow-scripts` is ":not(*)" so no scripts run

vlt install --allow-scripts=":root > #esbuild"
# only the version of esbuild that is a direct dependency of the project will be "built"

vlt run build --scope=":workspace > :dev"
# runs the "build" script for all workspace dev dependencies

This strategy effectively puts the power back in the hands of end-users without requiring changes to the script definitions themselves. I'd be happy if others stole this idea &/or we standardized around this broadly for most all capabilities of package management.

Somewhat related, there's likely the missing nuance that more advanced monorepo tools (ex. nx/turborepo) focus on in regards to the "task graph" - essentially a peer of the dep graph. Any changes to a such a popular script runner (like npm) should probably consider how modern teams are leveraging the task graph/pipelines.

[indexzero]

"I volunteer as tribute"

Fundamentally I see this as four problems:

1. no security policy for executing scripts: e.g. NODE_OPTIONS="--permission --allow-fs-read=/only/path/to/app --allow-fs-write=/only/path/to/app" would solve a lot (but of course not all) SHA1-Hulud cases

2. no "correct" path for binary packages: most modern packages today use optionalDependencies for this, but there are still a number of packages that use the legacy preinstall or postinstall approach to build those binary assets from source, not to mention the defaults baked in from 15+ years ago for npm rebuild

3. free-speech considerations for protest-ware: I personally view protest-ware as protected free speech. To restrict such speech writ large would be to diminish the principles from which npm was borne

4. social engineering / prompt injection vectors: this is the problem best classified as "what security have we truly given userland by preventing attacks on npm install when users / LLMs can easily be tricked into running those malicious scripts later?" A classic examples of this are the way in which puppeteer, playwright, and many others ask users to run a script when they first run the package. An LLM is going to run those scripts almost every time 🤔

Now I want to be clear that I don't disagree with anything @darcyclarke has laid down – the innovations of DSS (Dependency Selector Syntax) are material & powerful. It is simply that I believe in user-centric design. That is: the best solutions to this set of problems will come from thinking through & talking to both authors & consumers of npm packages to understand why they think that running these scripts is useful in the first place

[ljharb]

ftr I strongly disagree with number 3; you certainly have the right to speech, but not the right to speak inside my home without my permission, and my install terminal is my home. Anything unwanted that appears there is spam and should always be banned.

[indexzero]

ftr I strongly disagree with number 3; you certainly have the right to speech, but not the right to speak inside my home without my permission, and my install terminal is my home. Anything unwanted that appears there is spam and should always be banned.

We are all entitled to our opinions. I see little difference between a Twitter post and an npm package, both of which live inside your home on your computer, phone or other device. That said, in the interest of positive forward momentum I suggest we leave it at that and focus in on the problems that actually matter