• 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.