[Change] Make deprecation notices less scary
npm v10.4.0
What I did
npm install
What I saw
$ npm i
npm WARN deprecated [email protected]: 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 [email protected]: Glob versions prior to v9 are no longer supported
npm WARN deprecated [email protected]: Glob versions prior to v9 are no longer supported
npm WARN deprecated [email protected]: 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:
- npm only shows an explicit deprecation warning for a package when install the package, specifically. So
npm install eslintwould show a deprecation warning foreslintbut if I donpm installin my project that useseslint, that would not report an explicit deprecation. - If I do
npm installin 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
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.
If it leaks memory, maybe updating the package is a good idea.
Does anyone from the npm team actually monitor GitHub issues anymore?
This is a good feature request but we can't prioritize it at the moment.
@leobalter Understood. Would you be open to a pull request for this?
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).
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.