GeezerVison

I'm -1. I'm afraid this promotes using code that is deprecated/expected to be removed.

The major argument made in previous threads/discussions is that since this is a manual, opt-in flag, it's left up to the users to use good judgement. If I have done my research, and am happy using a deprecated or experimental feature, I should have a way to disable that specific warning message without having to introduce some monkey-patching of process.emitWarning (which is the current work around).

This option is not available on NODE_ENV so it's very obvious when it is enabled.

We already have --no-deprecation to disable deprecation warnings specifically. Why not something for experimental warnings (or any kind of warnings for that matter)?

I'm -1. I'm afraid this promotes using code that is deprecated/expected to be removed.

@anonrig I am not sure this works out in reality. For example, today most of the places I use --no-warnings today is when I am passing the output to other things and the usage is deep in a transitive dep. It has nothing to do with me using old features. I think it is better for us to offer selective off switches for the things than only have a global off switch.

I've added much more context including a previous TSC agreement comment to the PR body. I'd like us to not have the same debates as before. If this needs to be rediscussed at the TSC level so be it, and I encourage folks to read prior threads too.

I didn't block the PR. I'm just sharing my thoughts on this. Can you elaborate on the reasoning for hiding a specific warning? What's the benefit of hiding a warning, rather than all warnings? Why would someone want to hide specific warnings?

Why would someone want to hide specific warnings?

My thinking about being more "fine grained" here is that it incentivizes dealing with the warnings they can without resorting to silencing all of them and then getting bit by not knowing they were using a deprecated feature.

Can you elaborate on the reasoning for hiding a specific warning? What's the benefit of hiding a warning, rather than all warnings? Why would someone want to hide specific warnings?

This has been discussed in previous threads; I'll do my best to readdress it.

At a minimum, if I'm content using experimental features, I should have a way to disable those warnings (disable warning by type). Furthermore, if I am supporting some kind of legacy code path, and am content using a deprecated feature, I should have a way to disable specifically that deprecation warning, and not any others (disable warning by code). By "content" I mean that I have done my research and making the conscious decision to use something that may eventually be removed or changed. There are legitimate cases for this, such as maintaining an update branch of a project which runs on the latest version of Node.js in order to be prepared for future LTS changes.

Also mentioned in previous threads, Experimental Feature warnings should start using code, but that will come in a separate PR (I'll also contribute it).

1. Could you add an API to do this programmatically?
2. Could you add a test that verifies this is passed through correctly to worker_threads? (they can have their own node options)

I think this should be available in NODE_OPTIONS. Now that we're using .env files as de facto config files, we really shouldn't have any options that can't be specified in NODE_OPTIONS.

@GeoffreyBooth

I think this should be available in NODE_OPTIONS. Now that we're using .env files as de facto config files, we really shouldn't have any options that can't be specified in NODE_OPTIONS.

I'll defer to @jasnell as he was the one who previously commented against this position.

I'm happy to support either way.

@mcollina

Could you add an API to do this programmatically?

Do you mean something like process.disableWarnings(['DEP0025', 'ExperimentalWarning']) ?

Could you add a test that verifies this is passed through correctly to worker_threads? (they can have their own node options)

Yes 👍

CI: https://ci.nodejs.org/job/node-test-pull-request/55830/

Landed in a0b6638

👋 Is this change a candidate for back-porting into 20.x/18.x? (Congrats on getting this out in 21.x)