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?

@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.

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.

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.

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

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

@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

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.

@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).

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

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).

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

And here’s a plain old JavaScript version of it that also silences a few other experimental warnings (JSON modules, and Node.js specifier resolution):

const originalEmit = process.emit;

process.emit = function (name, data, ...args) {
  if (
    name === 'warning' &&
    typeof data === 'object' &&
    data.name === 'ExperimentalWarning' &&
    (data.message.includes('--experimental-loader') ||
      data.message.includes('Custom ESM Loaders is an experimental feature') ||
			data.message.includes('The Node.js specifier resolution flag is experimental') ||
			data.message.includes('Importing JSON modules is an experimental feature'))
  )
    return false

  return originalEmit.apply(process, arguments)
}

I happened to use a smaller version since your code isnt compatible if I use env instead of passing through nodejs' args

const originalEmit = process.emit;
  process.emit = function (name, data, ...args) {
    if (
      name === `warning` &&
      typeof data === `object` &&
      data.name === `ExperimentalWarning`
    )
      return false;

    return originalEmit.apply(process, arguments);
  };

Heres the bash script that runs mine:

NODE_OPTIONS=--experimental-vm-modules node test

(I bet you can add extra conditions to check env, but hey, your code would be not as performant as before then and will be 0.001% slower than before!)

The previous solutions didn't work for me in all cases, though process is an EventEmitter so the following coarse-grain one-liner worked for me:

process.removeAllListeners('warning');

Alternatively, a safer more fine-grained approach to only disable a specific type of warning (ExperimentalWarning in this case):

const warningListeners = process.listeners('warning');

if (warningListeners.length != 1) {
  console.warn(
    `expected 1 listener on the process "warning" event, saw ${warningListeners.length}`
  );
}

if (warningListeners[0]) {
  const originalWarningListener = warningListeners[0];
  process.removeAllListeners('warning');

  process.prependListener('warning', (warning) => {
    if (warning.name != 'ExperimentalWarning') {
      originalWarningListener(warning);
    }
  });
}

Eventually I'll publish this as @xunnamius/suppress-warnings with an interface like suppressWarnings(['ExperimentalWarning']) just to make my life easier.

I wrote a package that seems to do it for me atm: suppress-experimental-warnings. CI-tested with many different node versions + operating systems.

Vicious circle here:

1. if experimental warnings are impossible to be silenced as long as the features remain experimental, users will never dare throw real-life usages at those features
2. if users never dare throw real-life usages at those features, then those features will never be sufficiently "proven" by real life usage
3. if those features will never be sufficiently "proven" by real life usage, they will remain experimental forever

Something must yield in order to unstick this deadlock, and this feature request expresses the position that it is the warnings that should yield.

I wrote a package that seems to do it for me atm: suppress-experimental-warnings. CI-tested with many different node versions + operating systems.

With localizations too?

EDIT: just read your code above and indeed it doesn't seem to rely on output parsing. I'll give it a try.

I wrote a package that seems to do it for me atm: suppress-experimental-warnings. CI-tested with many different node versions + operating systems.

This seems to work pretty well FYI...