Repository navigation
Suppress specific warnings #40940
Description
Is your feature request related to a problem? Please describe.
We're currently using restify for some projects, and it relies on some deprecated functionality in Node (we don't use the bits that are deprecated, but they're still loaded). There is an issue on their side of the situation to remove the deprecated usage.
However, this results in a large number of deprecation notices in our logs that are noise, as we know about the deprecation and are aware that it doesn't impact what we're doing. We have the option to suppress all deprecation warnings with --no-deprecation, but this could cause us to miss other deprecations down the road.
Describe the solution you'd like
It'd be great if there was a way to only suppress specific warnings. Something as simple as --no-warnings=DEP0111
(Edit: This was originally suggested as --ignore-deprecation, but per 1, 2 & 3 I agree it makes sense to have a generic flag for all warnings)
Describe alternatives you've considered
There is the option to suppress all deprecation warnings with --no-deprecation, but as mentioned this could lead to us missing other deprecations that do impact us.
Activity
[-]Supress specific deprecation warnings[/-][+]Suppress specific deprecation warnings[/+]tniessen commentedon Nov 23, 2021
There are a few related discussions, see #36137, #31000, #40587.
jasnell commentedon Nov 23, 2021
I've said before, I'm +1 on this. I would extend it off the existing command line flag, e.g.
--no-warnings=DEP0111. This makes it generic to all types of warnings that have codes assigned.github-actions commentedon May 23, 2022
There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.
For more information on how the project manages feature requests, please consult the feature request management document.
MattIPv4 commentedon May 23, 2022
Would still love to see this implemented, esp. given the related work linked above that goes in a similar direction 💙
mcollina commentedon Jun 1, 2022
I'm +1 on this.
jwarkentin commentedon Jun 1, 2022
Seeing as #31000 was just closed in favor of this, it would be good to update the description to include experimental warnings. I don't know if they're implemented separately from deprecation warnings or not, but I'd hate to see this resolved only to leave #31000 completely unresolved with no issue tracking it.
alexpetros commentedon Jun 10, 2022
I came to this issue after following #31000 and it seems like there's a little bit of consensus on a flag that suppresses warnings by code. Would it be appropriate to a new issue that fully describes a generalized version of the flag, that could subsume this issue (and the ones linked above)?
10 remaining items
DakotaLarson commentedon Jul 30, 2023
Adding a +1 as my use case is very similar. Having to use --no-warnings feels like I am accepting more risk than necessary to leverage one experimental feature.
sebagr commentedon Aug 8, 2023
Yup, disabling all warning just to silence one doesn't seem right. +1
src: add `--disable-warning` option
src: add `--disable-warning` option
src: add `--disable-warning` option
src: add `--disable-warning` option
src: add `--disable-warning` option
src: add `--disable-warning` option
src: add `--disable-warning` option