Repository navigation
API for temporarily supressing experimental warnings #55505
Description
Spinned off from #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
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 warningsFor 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.
Activity
avivkeller commentedon Oct 23, 2024
WDYT about
process.noExperimentalfor parity withdoDeprecation, and you can set it to things like: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.
Etc
joyeecheung commentedon Oct 25, 2024
A polymorphic property can be more confusing, it's better to keep the type consistent.
DavidAnson commentedon Nov 3, 2024
As an author of a CommonJS tool that probes dynamic module names of unknown pedigree to
require/import()them appropriately, I found my way here after trying to enable Node 23 in CI. :)I appreciate the work on enabling
require(esm)and offer two thoughts for consideration:Thank you for your time and consideration.
PS - If interesting for any reason, this is the relevant code from
markdownlint-cli2:https://github.com/DavidAnson/markdownlint-cli2/blob/da711fa8b30421506086eb2dc7ea0a6c3cb27b9f/markdownlint-cli2.js#L88-L120
PPS - If there are better ways to implement this behavior, I'm happy to learn of them. There are some extra levels of indirection at play in the code above due to it needing to support dynamic module import after being Webpack'd and also needing to run in Node, browser, and VS Code (WebWorker) context.
github-actions commentedon May 3, 2025
There has been no activity on this feature request for 5 months. To help maintain relevant open issues, please add the never-staleIssues and PRs exempt from automated stale handling.
label or close this issue if it should be closed. If not, the issue will be automatically 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.
github-actions commentedon Jun 2, 2025
There has been no activity on this feature request and it is being closed. If you feel closing this issue is not the right thing to do, please leave a comment.
For more information on how the project manages feature requests, please consult the feature request management document.