Preventing pnpm from displaying too many deprecation warnings

[octogonz]

• I'd be willing to implement this feature (contributing guide)

Describe the user story

Our pnpm install always looks like this:

When a tool prints too many warnings, users conclude that the warnings are irrelevant noise. Everyone learns to ignore those warnings. This is a problem, because later if an actually important issue arises, everyone will ignore that warning.

Above we see two specific kinds of warnings:

1. PNPM is very slightly outdated. Is there any urgency to upgrade from PNPM 6.29.1 to 6.30.0? No there is not. My install logs have a giant yellow boxed banner, that looks very important, but is demanding that we do work which is definitely not worthwhile.

2. A bunch of dependencies are deprecated. Some of these should probably get fixed. However most of them are indirect dependencies that our users cannot control. We would need to ask the upstream package to fix the issue. Unless something is actually broken, people will generally choose to ignore the issue.

Describe the solution you'd like

Here's two ways to reduce the noise:

1. PNPM is very slightly outdated. Having a warning for outdated PNPM is useful. But could we configure it? For example, maybe we only want to be warned if our repo is a MAJOR version behind. Or maybe >= 10 minor versions? Also it might be useful if PNPM could flag releases that fix a critical issue (e.g. security vulnerability) -- this could be communicated using an NPM dist tag. That way we could ask for >= 10 minor versions OR a criticial fix

2. A bunch of dependencies are deprecated. For this issue, what would be awesome is a PNPM config file that can suppress individual warnings. That way when a new warning appears, our team can investigate the package, and if we decide not to upgrade, we could record this in a config file so that PNPM no longer warns about that issue. This would eliminate the "noise that everybody ignores" problem.

[zkochan]

The update notifier is not a warning. It is an info message. Currently it can be printed once a day:

pnpm/packages/pnpm/src/checkForUpdates.ts

Line 14 in e6cc674

const UPDATE_CHECK_FREQUENCY = 24 * 60 * 60 * 1000 // 1 day

Is it too frequent? I prefer users to use the latest version to get the best experience. We can change how the update notice looks like.

Regarding the warnings. I think there are two frequent sources of warnings. Deprecated deps and peer deps. For peer deps we already have settings to mute those warnings. For deprecated packages, we may add some new setting.

Maybe something like:

{
  "pnpm": {
    "allowDeprecated": {
      "fsevents": "*",
      "request": "2"
    }
  }
}

[octogonz]

Currently it can be printed once a day

That doesn't really help. Our CI jobs run on a clean VM, so the message will appear in every CI log regardless.

And if the notice is useful/relevant to someone, they might find it rather annoying that the message mysteriously disappears when you run pnpm install a second time. ("PNPM is telling us to upgrade this repo." "What are you talking about, I just ran pnpm install and I don't see any notice - did you confuse it with some other repo?" "Weird, I swear I saw a warning!") Build tools are expected to behave deterministically.

Is it too frequent? I prefer users to use the latest version to get the best experience.

🤔 Thinking about this, everything you said actually makes sense for an individual person who installed PNPM themselves, and who can simply run pnpm add -g pnpm.

What's causing the trouble is that in a large corporate monorepo:

1. For individual developers, their global NPM commands are installed by an automated shell script, so pnpm add -g pnpm is not even the correct way to update. (The message should be like Please run setup.sh again.)

2. The upgrade alert assumes that pnpm was invoked interactively, i.e. it thinks it is talking to a person. But most of the time PNPM was invoked by a build script, possibly on remote CI machines, so these alerts are polluting log files.

3. In our monorepo, users invoke pnpm install by running rush install which does not even use the global version of PNPM. Rush installs the deterministic pnpmVersion specified in rush.json, which depends on your Git branch. The only way to make PNPM happy is to make a PR that updates rush.json, which is asking a lot more than simply running pnpm add -g pnpm on "your machine."

Maybe all of these problems could be addressed by adding a CLI parameter or environment variable that tells PNPM it is being invoked by some other system. For example pnpm --non-interactive.

In this --non-interactive mode, the big upgrade notice could be replaced by a simple banner like:

PNPM version 6.29.1 (latest is 6.30.0)

...or if there is a critical fix, it might show something like this:

PNPM version 6.29.1 (latest is 6.30.0)
Notice: Version 6.29.1 has a known issue; please upgrade PNPM.

[octogonz]

For deprecated packages, we may add some new setting.

Maybe something like:

{
  "pnpm": {
    "allowDeprecated": {
      "fsevents": "*",
      "request": "2"
    }
  }
}

That sounds great. 👍

Can this setting be specified once for the entire workspace?

[zkochan]

Yes, this would be specified in the package.json that is in the root of the repository.

[octogonz]

Yes, this would be specified in the package.json that is in the root of the repository.

Rush repositories do not have a top-level package.json. The pnpm-workspace.yaml file gets generated as a temporary file in a subfolder common/temp. In this usage, will PNPM look for settings in common/temp/package.json?

[zkochan]

where is the lockfile created? Also in common/temp?

[octogonz]

Yes, we have:

• common/temp/package.json
• common/temp/pnpm-workspace.yaml
• common/temp/pnpm-lock.yaml

The command line looks like:

pnpm install --store C:\Git\rushstack\common\temp\pnpm-store --frozen-lockfile --strict-peer-dependencies 
  --recursive --link-workspace-packages false

...so if we are able to store settings in common/temp/package.json, I wonder if we could move all of these CLI parameters in there as well.

CC @D4N14L @iclanton

[zkochan]

Yes, you can use that package.json file. The CLI options cannot be moved there. But you can move them to a .npmrc file in that directory, if you want.

[zkochan]

🚢 7.2.0

[octogonz]

Thank you! 🎉