Suppress specific warnings

[MattIPv4]

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.

[tniessen]

There are a few related discussions, see #36137, #31000, #40587.

[jasnell]

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]

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]

Would still love to see this implemented, esp. given the related work linked above that goes in a similar direction 💙

[mcollina]

I'm +1 on this.

[jwarkentin]

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]

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)?

[usrtax]

any update ?

[MattIPv4]

👀 Updated the title/desc to capture suppressing all warning types, not just deprecations 👍

[rauschma]

My use case is this: I’m importing JSON from an ESM module in a CLI app. Seeing a warning every time I do that, messes up the user interface of the app.

[FrontHorn]

I would also like to have the ability to suppress a specific warning. We interact with a number of APIs that require the NODE_TLS_REJECT_UNAUTHORIZED to be set to 0. We switch the variable back to 1 as soon as the associated call is returned but the logs are filled with warning noise.

[tniessen]

I would also like to have the ability to suppress a specific warning. We interact with a number of APIs that require the NODE_TLS_REJECT_UNAUTHORIZED to be set to 0. We switch the variable back to 1 as soon as the associated call is returned but the logs are filled with warning noise.

Side note: it might be a good idea to use the rejectUnauthorized option instead (or to implement proper verification).

[github-actions]

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.

[FrontHorn]

I would also like to have the ability to suppress a specific warning. We interact with a number of APIs that require the NODE_TLS_REJECT_UNAUTHORIZED to be set to 0. We switch the variable back to 1 as soon as the associated call is returned but the logs are filled with warning noise.

Side note: it might be a good idea to use the rejectUnauthorized option instead (or to implement proper verification).

Whilst I agree with the implementation of proper verification, there are other components at play that we do not have the ability to change, a lot of them legacy & no longer maintained. Whilst switching the flag from 1 to 0 and back again may not be the best method, in the cases where we do this, it is the only option that works.

[DakotaLarson]

My use case is this: I’m importing JSON from an ESM module in a CLI app. Seeing a warning every time I do that, messes up the user interface of the app.

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]

Yup, disabling all warning just to silence one doesn't seem right. +1