API for temporarily supressing experimental warnings

[joyeecheung]

Spinned off from https://github.com/nodejs/node/issues/55417 to discuss about this more generally.

While it can be abused and lead to unwanted issues, I think CLI tools tend to inevitably want to do it for a cleaner output and will find their way to do it already. One example that I've found previously was how Yarn does it by temporarily monkey-patching process.emit

https://github.com/yarnpkg/berry/blob/031b5da1dc8e459e844efda137b2f00d7cdc9dda/packages/yarnpkg-pnp/sources/loader/applyPatch.ts#L304-L325

So I think we might as well provide a proper API for this instead of having users resort to monkey-patching.

We could either just have something quick and simple like process.noExperimentalWarning toggle that gets checked before the warning is emitted (similar to process.noDeprecation):

// Temporarily turn off the warning
process.noExperimentalWarning = true;
// ...use the experimental API
// process.noExperimentalWarning = false;

Or some API that toggles specific warnings (this requires assigning code to experiments, which we currently do not have):

process.silenceExperimentalWarning && process.silenceExperimentalWarning('EXP1', true);
// ...use the experimental API
process.silenceExperimentalWarning && process.silenceExperimentalWarnings('EXP1', false);

Or some API that takes a function and run it without emitting warnings (may be a bit awkward for async APIs, but ensures that users don't forget to toggle it back):

process.runWithoutExperimentalWarning(() => {
   // ...use the experimental API
}, 'EXP1');  // if the experiment code is not passed, silence all experimental warnings

For the ones that take codes we could also merge it with deprecation warning handling and just have e.g. process.silenceWarning()/process.runWithoutWarning() that also accepts DEP codes.

More ideas are welcomed, too.

[RedYetiDev]

WDYT about process.noExperimental for parity with doDeprecation, and you can set it to things like:

true // disable all
"EXPZZ" // disable "EXPZZ"
["EXPZZ", "EXPYY"] // disable both

---

Even more so, we could condense the no-deprecation and no-experimental into a single disable-warnings functionality, where codes for both can be specified.

E.G.

process.noWarnings = "EXP" // All experimental
process.noWarnings = "DEPZZ" // DEPZZ
process.noWarnings = [<codes>] // <codes> are disabled

Etc

[joyeecheung]

A polymorphic property can be more confusing, it's better to keep the type consistent.