[RRFC] Deprecated packages: automatically display dependents, to ease notifying maintainers

[dandv]

Motivation ("The Why")

Very often when users install a package, they see warnings about deprecated dependencies, and don't know what to do about them.

Example

Here are some examples from StackOverflow of user confused by this:

• NPM warn message about deprecated package
• npm deprecated warnings – do I need to update something?
• How to deal with deprecation warnings from npm
• npm install and deprecated warnings
• Getting npm WARN deprecated

How

Current Behaviour

Desired Behaviour

npm could automatically integrate the output of npm ls <deprecated-package:

$ npm install
npm WARN deprecated popper.js@1.16.1: You can find the new Popper v2 at @popperjs/core, this package is dedicated to the legacy v1
└─┬ @material-ui/core@4.10.0
  └── popper.js@1.16.1 

[isaacs]

This is a good idea, but I wonder if it even needs an RFC. I'd be fine just doing this in npm v7. The only downside I could imagine is that it might get a bit noisy if you have a popular module that's deprecated, or a bunch of deprecated modules under a single top level dep.

There's definitely a need for us to rethink a lot of the design of our various warning outputs, this would be a good candidate for consideration there.

[dandv]

I'd be happy to see that in v7 as well. Should I file the issue somewhere else (it can also be moved to a different GitHub repo by an org owner, but no problem to file it again in the cli repo for instance).

As for popular deprecations, the noise should incentivize solutions :)

[ruyadorno]

I think this idea goes really well with the new npm explain command! Let me put it in the agenda so that we can get it back in our radar for post-v7.0.0.

[ruyadorno]

Action item from the OpenRFC call:

• Follow up RFC/PR that adds a post-install notification (similar to audit and fund) that aggregates the number of deprecated packages and surfaces that info to the user while also removes all the current warnings during install time, user then could optionally run a subcommand such as npm explain deprecation in order to get the detailed info.

[ruyadorno]

Thanks for bringing up this idea @dandv! Feel free to follow up with the proper RFC if you're interested in championing this change 😊 otherwise it will just have to wait a little longer until someone from the team has the bandwith to pick it up but after the discussion in the call it def sounds like an area we want to improve in the cli. Thanks again for your contribution 😄

[darcyclarke]

@dandv @ruyadorno Just to quickly follow up, I think npm explain deprecation should actually be npm explain --deprecation (since explain currently expects the second arg to be a spec). Thinking about it a bit as well, it may make sense that the same flag is supported by npm ls 🤔. Either way, an example of how this could work/look:

$ npm install express@2

added 6 packages, and audited 6 packages in 870ms

3 deprecated packages found

To find out more, run:
  npm explain --deprecated 

4 vulnerabilities found (1 low, 1 moderate, 2 high)

To address all issues (including breaking changes), run:
  npm audit fix --force

Run `npm audit` for details

[ruyadorno]

Let's continue the conversation over here: #516