Ability to suppress warnings by type (or just experimental warnings)

[coreyfarrell]

Is your feature request related to a problem? Please describe.
I'd like to suppress experimental warnings while still seeing any other errors. In particular when I am using native ES modules I do not want the experimental warning printed for every process, but I do want unrelated warnings to still be printed.

Describe the solution you'd like
Allow --no-warnings to optionally accept an option string such as --no-warnings=type1,type2. Using --no-warnings without any option would continue to disable all warnings. This would allow --no-warnings=ExperimentalWarning to suppress ExperimentalWarning only.

Describe alternatives you've considered
--no-experimental-warnings or a similarly named new flag could be created. This has the drawback that node --no-experimental-warnings on node.js 13.3.0 exit with an error where --no-warnings=ExperimentalWarnings will not currently error (it causes all warnings to be ignored).

In my own repo which uses ES modules I've created suppress-experimental.cjs which gets loaded with NODE_OPTIONS='--require=./suppress-experimental.cjs':

'use strict';

const {emitWarning} = process;

process.emitWarning = (warning, ...args) => {
	if (args[0] === 'ExperimentalWarning') {
		return;
	}

	if (args[0] && typeof args[0] === 'object' && args[0].type === 'ExperimentalWarning') {
		return;
	}

	return emitWarning(warning, ...args);
};

Obviously patching node.js internals like this is undesirable but it accomplishes my goal.

[JoshMcCullough]

args[0] would point to a string, since the arguments to emitWarning are warning: string | Error, name?: string, ctor?: Function. Are you sure this code is working correctly?

[coreyfarrell]

@JoshMcCullough Yes the code works, note that the parameters for my replacement function are (warning, ...args). I can see how that looks odd but it definitely works.

[JoshMcCullough]

I was suggesting that your args[0] will always be a string since it maps to the 2nd parameter of emitWarning, which is (if the types are correct), name?: string. So the second if block would never be entered -- unless I'm totally missing something here.

[coreyfarrell]

https://nodejs.org/dist/latest/docs/api/process.html#process_process_emitwarning_warning_options shows that process.emitWarning can also take an options object as the second argument. I don't think the ESM warning uses that style call but I still check for it as I want my code to continue working if the ESM warning switches to the options object.

[noahehall]

this would have been cool, especially for those of us using experimental loader (which I presume will be experimental for quite some time?)

[ChuanyuanLiu]

The proposed hack with suppress-experimental.js did not work for me.

It works when I trigger process.emitWarning manually but it appears that NodeJS's call on Experimental Warning did not go through the redefined process.emitWarning.

My cmd arguments are node --experimental-fetch --require=./suppress-experimental.js index.js

[kachkaev]

@ChuanyuanLiu which version of Node are you using? Overriding process.emitWarning as suggested above worked for me on Node 16, but when I tried Node 18, it did not. It indeed feels like (node:43369) ExperimentalWarning: ... comes from some internals of Node, so cannot be silenced.

UPD I found a patch that works both in Node 16 and 18 🎉
https://github.com/yarnpkg/berry/blob/2cf0a8fe3e4d4bd7d4d344245d24a85a45d4c5c9/packages/yarnpkg-pnp/sources/loader/applyPatch.ts#L414-L435

[JakobJingleheimer]

A recent change (#42314) converted some of ESMLoader's experimental warning emissions from using process.emitWarning() directly to an internal utility (emitExperimentalWarning()) that uses it under the hood. Since it still uses process.emitWarning() under the hood, if overwriting process.emitWarning() ever worked, that should continue to work.

[kachkaev]

@JakobJingleheimer looks like in Node 18 uses process.emit instead of process.emitWarning. Judging by a recent change in Yarn Berry: yarnpkg/berry#4338 (diff).

[JakobJingleheimer]

Could you cite a problematic place where that happens? A quick search of the node codebase suggests it's used only sparingly and in very specific scenarios. process.emitWarning does call process.emit():

emitWarning → doEmitWarning → emit

node/lib/internal/process/warning.js

Lines 155 to 160 in c3aa86d

	process.nextTick(doEmitWarning, warning);
	}
	function emitWarningSync(warning) {
	process.emit('warning', createWarningObject(warning));
	}

but it has done so for ~2 years (according to git history).

I'm not aware of a policy change and I see no code docs recommending such a switch (and if it did happen, it was apparently incomplete). It's quite possible one of the ~100 active maintainers used something different recently, either because it was better suited or because they didn't know process.emitWarning() exists.

P.S. Regarding the original topic of this issue, I don't foresee suppressing certain warnings being supported (and it would take a significant amount of work to facilitate as there is currently no authoritative list of feature names, only strings that happen to be consistent because humans care to check).

[karlhorky]

Ok, opened an issue here:

• Ability to suppress warnings by type #47478

[Cojad]

I want a solution which is simple yet easy to port to any project using fetch. So I shorten it into just 2 lines of code in my entry script.

// Using only 2 line at begining of your entry script(ex: index.js).
// Or any place before using fetch to suppress warnings for ExperimentalWarning(just once before calling fetch).

// inspired by 
// https://github.com/nodejs/node/issues/30810#issuecomment-1433950987
const { emit: originalEmit } = process;
process.emit = (event, error) => event === 'warning' && error.name === 'ExperimentalWarning' ? false : originalEmit.apply(process, arguments);

[jeffs]

const { emit: originalEmit } = process;
process.emit = (event, error) => event === 'warning' && error.name === 'ExperimentalWarning' ? false : originalEmit.apply(process, arguments);

That arguments object isn't from your wrapper function; it's a free variable. The arguments object isn't defined by fat arrow functions. You're accidentally passing originalEmit an unrelated arguments object that Node apparently puts in the prelude for scripts (though not for the REPL), and dropping your actual parameters. Consider using a rest parameter instead. See also MDN.

Maybe you could share a GitHub repo or NPM package complete with unit and integration tests. It would be nice if your solution also type-checked properly. I'm sure folks would be happy to review your code.

[liudonghua123]

I add a shebang like this to make the bin script working without showing the warnings. And it works for windows too.

#!/usr/bin/env node --no-warnings=ExperimentalWarning

[egasimus]

I add a shebang like this to make the bin script working without showing the warnings. And it works for windows too.

#!/usr/bin/env node --no-warnings=ExperimentalWarning

On my Linux box, this needs to be:

#!/usr/bin/env -S node --no-warnings=ExperimentalWarning

The -S flag is needed to split the command line arguments. Without it, the script just hangs, doesn't even start. Does macOS env support the -S flag?

I saw somebody do an executable Dockerfile with env -S recently - but does it work out of the box on all platforms today?

The other thing you gotta keep in mind when starting a script with a shebang is that it becomes unimportable in <script type="module">. Which is mostly fine for a CLI entrypoint unless you want to write an entire isomorphic app in 1 file, in which case, no dice 😅

[liudonghua123]

@egasimus Yes, I also find this option is necessary when running on linux.

see also liudonghua123/node-sea@04fa6ec.

[egasimus]

@liudonghua123 Yes. Does it still work on Mac and Windows when you add that option?

[liudonghua123]

@liudonghua123 Yes. Does it still work on Mac and Windows when you add that option?

It works on windows and linux, I have not tested on macos yet.

[rauschma]

Also works on macOS! I just tested it.

[Sv443]

Hi, does anyone know a way of doing this with just environment variables? In my case I have no access to the args of the node binary.

[cjihrig]

does anyone know a way of doing this with just environment variables?

$ NODE_OPTIONS=--disable-warning=ExperimentalWarning node -e 'require("node:vm").measureMemory()'

[o0101]

Can node process set its own process.env.NODE_OPTIONS ? Or will that not have effect after startup