Possible problems and their solutions while trying to prevent spam on npm package installations.

npm packages still print spam, despite having `DISABLE_OPENCOLLECTIVE=true`.md

Summary

1. Make sure you also set OPENCOLLECTIVE_HIDE=true. Some packages check for this one and not DISABLE_OPENCOLLECTIVE, while some others check for DISABLE_OPENCOLLECTIVE and not OPENCOLLECTIVE_HIDE. Hence, set both. Note that in the future, you might encounter another package that does not support any of these variables, but some other ones. In that case, update this list.

2. You (most likely your package-lock.json file) has an older version of a "spammer" package. This older version does not respect the "no-spam" environment variables such as DISABLE_OPENCOLLECTIVE=true, because it (the older version) is missing the code ("logic") that checks for the presence of these "no-spam" environment variables and omits printing the spam messages in the case of their presence. The solution is to update ("upgrade") your package-lock.json, so that you will have the more recent versions of the "spammer" packages that check for the presence of "no-spam" environment variables and omit printing the spam, in case of presence of the no-spam environment variables.

   For example, for core-js, the 2.6.11 version and below does not support the "no-spam" config, whereas 2.6.12 and above ("above" means between 2.6.12 and 2.6.N, where N > 12. For other "major" and "minor" versions, it depends on which "patch" version they received the "no-spam" update) supports it.

Also important to note is, nodemon has a "custom logic" for showing the spam message or not. That is, even if you have an older version of nodemon which does not check for the presence of the "no-spam" environment variables, installing nodemon might not result in a spam message being printed. How? Well, there is "custom logic" in nodemons postinstall script that shows the message only if it has been more than a week since the last time the message was shown:

// ...
const conf = new Configstore(pkg.name);
const last = conf.get('lastCheck');

if (!last || now - week > last) {
  console.log(message);
  conf.set('lastCheck', now);
}
// ...

So, nodemon can still not show the message even if you have an older version installed which does not check for the presence of "no-spam" environment variables, or when you don't have the "no-spam" environment variables that nodemon "accepts". Notably, instead of accepting DISABLE_OPENCOLLECTIVE=true, nodemon checks for the presence of OPENCOLLECTIVE_HIDE environment variable.

Details

Numerous npm packages spam your terminal window by printing irrelevant nonsense. Recently, there is a convention to suppress these messages. This convention is to have an environment variable with name DISABLE_OPENCOLLECTIVE and value true. That is, you can put export DISABLE_OPENCOLLECTIVE=true to your .bash_profile and hopefully, most of the spammer npm packages will play along nicely and stop spamming you, upon encountering this environment variable.

However, this does not always seem to work. For example, I have this environment variable, but I still got many spam messages when I checked out a Node.js project and run npm install on it. The interesting part is, when I delete package-lock.json (and node_modules/) and run npm install again, this time there don't seem to be any spam happening. How is this possible?

Well, the answer is, the "no-spam" behavior is completely at the will of a package. That is, during installation, a package may print out messages. Among these messages, the irrelevant ones can be categorized as "spam". However, it is not trivial to tell which one of these messages would be categorized as "spam" and which ones not. Hence, unless we don't care about not reading ("missing") the no-spam messages as well, there is no easy solution for detecting and filtering out the "spam messages" vs. the "no-spam ones". If we didn't care about "missing" the no-spam messages as well, we could just devise a solution that blocks all output during installation, or in the postinstall script. However, if we do care about reading the "no-spam" messages, and filtering out only the spam ones, basically the only "proper" solution is to rely on the package to distinguish between the spam and no-spam ones, and for the package to give us an option to disable the spam ones, at the package's own will, through a mechanism such as setting an environment variable. That is, if the package does not support this "don't print spam if a set of environment variables are present" behavior, then there is no easy way to filter out only the spam messages, and keep the non-spam ones.