Open joyeecheung opened 2 days ago
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
A polymorphic property can be more confusing, it's better to keep the type consistent.
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 toprocess.noDeprecation
):Or some API that toggles specific warnings (this requires assigning code to experiments, which we currently do not have):
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):
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 acceptsDEP
codes.More ideas are welcomed, too.