[FEATURE] Allow customizing packages on install

[begriffs]

What / Why

Currently running npm install fetches and installs a package as-is. However it would be more flexible to be able to specify a patch to apply at installation time to customize a package. One use case is to modify the package source to remove donation banners in install logs.

This is complementary to -- and more general than -- #80.

When

At install time, with the presence of a new flag.

How

Add a --patch /path/to/my.patch option to npm install. NPM would then fetch the source as usual, run patch -p0 < /path/to/my.patch to apply the customization, and continue with the normal installation process.

Example

Suppose you want to install core-js without its donation banner breaking your continuous integration. You can already use npm install --loglevel silent, but this will silence other potentially useful messages.

Instead, the user could create a patch file, e.g. nobanner.patch:

--- packages/core-js/postinstall.js
+++ packages/core-js/postinstall.js
@@ -52,5 +52,3 @@
   // eslint-disable-next-line no-console,no-control-regex
   console.log(COLOR ? BANNER : BANNER.replace(/\u001B\[\d+m/g, ''));
 }
-
-if (isBannerRequired()) showBanner();

Then, using the proposed feature, run:

npm install --patch nobanner.patch core-js

[isaacs]

If this is really about donation request banners, they're being phased out in favor of the funding package.json stanza and npm fund command anyway. So I'd like to see another use case, at least, since that one won't matter soon enough.

What happens when the patch doesn't apply?

This feels like one hell of a footgun. I have deep misgivings about supporting it.

[begriffs]

If this is really about donation request banners, they're being phased out in favor of the `funding` package.json stanza and `npm fund` command anyway. So I'd like to see another use case, at least, since that one won't matter soon enough.

There is no other concrete example I know of. Basically I saw some Github issues that were full of drama about the banners, and wondered to myself if there was a technical solution that would allow project authors to keep the banners if they wanted while letting package consumers customize it if they cared enough. The patching idea seemed a simple mechanism that is open-ended enough to possibly apply to other things.

What happens when the patch doesn't apply?

On failure the patch utility exits with a non-zero code, and npm install could fail with an error.

This feels like one hell of a footgun. I have deep misgivings about supporting it.

After thinking about the idea again today, I realized that it may not fix the original motivation. The banners seem to cause problems when they appear in deep dependencies, whereas the `--patch` mechanism applies only when installing a package directly. You could perhaps specify patches for dependencies, but that feels a lot more complicated and is probably not worth it.

[isaacs]

Ok, then I'm gonna close this.

I know that there are registry-side tools that float patches like this, typically for security patches or bugfixes, but it seems like not an ideal fit for the cli.

Thanks for bringing it up, all the same :)

[markcellus]

FWIW, patch-package would be great for this use case.