[Change] Make deprecation notices less scary

[nzakas]

npm v10.4.0

What I did

npm install

What I saw

$ npm i
npm WARN deprecated inflight@1.0.6: This module is not supported, and leaks memory. Do not use it. Check out lru-cache if you want a good and tested way to coalesce async requests by a key value, which is much more comprehensive and powerful.
npm WARN deprecated glob@8.1.0: Glob versions prior to v9 are no longer supported
npm WARN deprecated glob@7.2.3: Glob versions prior to v9 are no longer supported
npm WARN deprecated glob@7.2.3: Glob versions prior to v9 are no longer supported

What's happening

The default behavior of npm is to warn about every deprecated packages in the entire installation, regardless of how deep it is inside of the dependency tree. In this case, these packages are used by eslint, and therefore, I personally don't have the ability to make any changes.

And as the maintainer of ESLint, we've been getting inundated with complaints about this even though these packages work fine.

Proposal

I'd like to propose the following changes:

1. npm only shows an explicit deprecation warning for a package when install the package, specifically. So npm install eslint would show a deprecation warning for eslint but if I do npm install in my project that uses eslint, that would not report an explicit deprecation.
2. If I do npm install in my project and any of my direct dependencies are deprecated, output something along the lines of:

16 dependencies are deprecated
  run `npm deprecated` for details

[ljharb]

This is something we discussed back when RFC calls were a thing, and the plan was to enact this exact proposal, but sadly it never got prioritized.

[andremarcondesteixeira]

If it leaks memory, maybe updating the package is a good idea.

[nzakas]

Does anyone from the npm team actually monitor GitHub issues anymore?

[leobalter]

This is a good feature request but we can't prioritize it at the moment.

[nzakas]

@leobalter Understood. Would you be open to a pull request for this?

[leobalter]

Pull Requests are welcome! Saying that, I believe this might open some rabbit holes on how the implementation complexity.

I'd personally like the idea of summarizing the deprecated messages and perhaps print out only the messages for top level dependencies.

The complexity comes out when we think on where to expand it. I'd avoid a new npm deprecated and probably explore something like npm audit deprecated (we already have npm audit signatures).

[nzakas]

Got it. I'll see if I can find some time to dig in a bit and come up with something, understanding that it won't be perfect from the start. I'd just like to help get the ball rolling.