Standard way to write a message after package install

[ark120202]

Do you want to request a feature or report a bug?

Feature

What is the current behavior?

There are more and more packages that add a postinstall script to write some message after installing a package, usually suggesting to support package's author. There are few issues with this:

• Yarn collapses scripts' stdout, so these messages don't get displayed at all (related to Postinstall script is not being executed  #5476)

• Since there are no any guidelines, instead of simply logging message it might do web requests, require huge dependencies, or write a lot of text, seriously slowing install process

• Since usually modules don't have any scripts I remember all these modules, so noticing a new module makes me check what exactly is being executed. If more modules would adopt that practice, a new module appearing there won't be a surprise, but it actually might be a malicious script

What is the expected behavior?

Provide a new field in package.json (for example installMessage) to specify a message that would be printed after installing a module. Additionally, it may add a limit to the length of logged message and add a config option to opt-out of it.

Thread on npm community

[arcanis]

Yep, I agree. I actually opened a thread on OpenCollective some time ago to tell them that they shouldn't do this, but didn't get answers back then.

The problem with these kind of features is that it requires adoption otherwise it's pointless, and at the moment I'm already a bit spread thin in terms of advocating for new features.

[feross]

@arcanis Thank you for taking the initiative to open the issue on the OpenCollective repo.

these kind of features is that it requires adoption

If yarn were to add a feature that allowed me to annotate that a given install script does not produce build artifacts, I would adopt it in the funding package. Then yarn would be free to run the script without it assuming that build artifacts are produced. Would this help prevent the de-optimization you mentioned?

The other issue that would need to be resolved as part of this effort is for postinstall output to not be suppressed.

[arcanis]

My ideas so far are based on the following items:

• We want to allow package authors to notify their existence to their users
• We don't want to clutter the install output with too many messages (this is also for the sake of package authors; too many messages would make them de-facto invisible)
• I don't want to encourage package authors to add postinstall scripts to their packages (for the reason I mentioned, but also because I want to increase the incentives to be postinstall-less for security reasons)

In this context, I don't think using the postinstall scripts to print messages is a good idea. Packages will compete for attention, and even if we make it slightly easier for package managers to optimize things around I'm not sure the ecosystem will be in a better spot in the end. So I was considering a new field in the package.json:

{"awareness": "... some message left to the user ..."}

Then, when running yarn add we would print the awareness field for all newly installed packages (potentially with a maximal width to prevent one package increasing its width just to be noticed more than the others?).

Additionally, when running yarn install we would print the awareness field for up to three random packages (too many would cause users to not see them).

This feature would only be available to packages that do not list postinstall scripts (it's a bit tricky because they could workaround this by depending on another package that would have a postinstall script, but I can likely figure out a way to prevent that). Some discussion would have to be made regarding whether transitive dependencies should be taken into consideration.

How does that sound? I can make a formal RFC post-v2 (around the end of the year) and include authors of packages that do similar things (@zloirock comes to mind, I might be interested myself at some point).

[feross]

@arcanis This proposal sounds perfect. Note: npm is also working on something similar. Would be great if the package.json field name used were the same.