Can we supress the new experimental warning from the new default require(esm) setting?

[futuremotiondev]

What is the problem this feature will solve?

I use NVM for Windows.

1. I run nvm install 23.0.0
2. v23.0.0 gets installed.
3. I then run nvm use 23.0.0
4. I then run npm install npm@latest -g

The latest npm gets installed, but I also get the following output pollution:

(node:32728) ExperimentalWarning: Support for loading ES Module in require() is an experimental feature and might change at any time
(Use `node --trace-warnings ...` to show where the warning was created)

5. If I then run npm install svgo -g, I get the same ExperimentalWarning pollution.

Is there any way I can suppress this message by default while still leaving the new default require(esm) setting enabled? I don't want to see this warning every time I install a global package, especially since I am automating things.

This doesn't happen with any node versions prior to 23.0.0.

Appreciate any consideration.

What is the feature you are proposing to solve the problem?

A global configuration setting to suppress this new warning every time I install a global module in v23.0.0:

(node:32728) ExperimentalWarning: Support for loading ES Module in require() is an experimental feature and might change at any time
(Use `node --trace-warnings ...` to show where the warning was created)

What alternatives have you considered?

Nothing yet.

[targos]

You can use node --no-deprecation or export NODE_OPTIONS="--no-deprecation".

[targos]

Or disable require('esm') with --no-experimental-require-module

[futuremotiondev]

You can use node --no-deprecation or export NODE_OPTIONS="--no-deprecation".

How can I do this globally though?

export NODE_OPTIONS="--no-deprecation" in console just gives me

export: The term 'export' is not recognized as a name of a cmdlet, function, script file, or executable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

Am I missing something?

[futuremotiondev]

I also created a machine-wide environment variable called NODE_OPTIONS and set its value to --no-deprecation. I'm still getting the ExperimentalWarning. It's even happening when I run npm list -g --depth=0.

And yes I tried restarting the console so the environment variable gets refreshed, but still the same output.

---

EDIT: Printing $env:NODE_OPTIONS in PowerShell after restarting my host and console outputs a blank line instead of my set value of --no-deprecation

[targos]

I don't know much about Windows, sorry.

[avivkeller]

This feature is experimental, so it emits a warning. IMHO this is working as intended.

If npm is using an experimental feature, it should be their responsibility to figure out how to handle the warning

[climba03003]

I believe he is asking for a way to not showing the warning. https://nodejs.org/api/cli.html#--disable-warningcode-or-type

node --disable-warning=ExperimentalWarning

[indriyam]

Having same error. Partly resolved in local terminal by removing and installing node and npm. Now when running from local terminal no error message. Else this was throwing whenever I was using npm like npm install, npm start etc.

Also installed tsx and recommended in search. So that works without error.

But when using skaffold dev it getst stuck at the following two lines #9 [4/5] RUN npm install --omit=dev #9 2.481 (node:1) ExperimentalWarning: Support for loading ES Module in require() is an experimental feature and might change at any time #9 2.481 (Use node --trace-warnings ... to show where the warning was created) In my case it is not moving further and fails when press Ctrl+C after waiting... So it not just warning. It hangs out so issue is critical to me. Wondering how it was working all good till. In last three days, this issue props up.

Lot of googling but no luck.

[MikeMcC399]

@RedYetiDev

This feature is experimental, so it emits a warning. IMHO this is working as intended.

If npm is using an experimental feature, it should be their responsibility to figure out how to handle the warning

• There is now a separate npm issue open: https://github.com/npm/cli/issues/7857. I suspect however that [email protected] is not intending to use any experimental feature. The warning impacts basic usage of npm so it is going to have widespread impact.

For example, even with no npm modules installed, executing npm view npm version results in the ExperimentalWarning:

$ npm view npm version
(node:5212) ExperimentalWarning: Support for loading ES Module in require() is an experimental feature and might change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
10.9.0

Many other often-used npm cli commands also provoke the warning:

npm audit
npm ci
npm doctor
npm init
npm install
npm install-ci-test
npm ls
npm outdated
npm prune
npm repo
npm show
... etc

[avivkeller]

My point is, I don't believe this is a bug in the Node.js project. In npm–perhaps, however, on this side of the ecosystem, at least how I see it, the feature should, by default, emit a warning.

[MikeMcC399]

• I guess we need some feedback from the npm team in https://github.com/npm/cli/issues/7857 to see if they can make any adjustments to npm to stop the experimental warning from being triggered in Node.js 23.x. I tried enabling --trace-warnings, however that didn't pin-point the source for me.

[MikeMcC399]

The warning from npm 10.9.0 under Node.js v23.0.0 comes from the use of the ESM version of supports-color >= 9.0.0 by npm with debug using require() to test if supports-color is available.

See the following for more details:

• https://github.com/debug-js/debug/issues/975
• https://github.com/npm/cli/issues/7857

Edit: The above issues are now closed, since the problem was resolved with the release of Node.js v23.4.0 on Dec 10, 2024

[joyeecheung]

as @climba03003 mentioned in https://github.com/nodejs/node/issues/55417#issuecomment-2422082038 - for the end users, if they want to supress the warning, they could use

node --disable-warning=ExperimentalWarning entry.js

Or if it's run by an executable that's not node itself, use the NODE_OPTIONS=--disable-warning=ExperimentalWarning environment variable.

For a package that does require(esm) either on purpose or for fallback, maybe we can add a toggle to e.g. process to disable it temporarily, similar to process.noDeprecation. Though I am a bit worried about how much good it does if abused. Also the warning is mostly for v23. For v22 we will supress warnings from code within node_modules and v24 will probably not have the warning as it should be stable by then.

[jpike88]

"For v22 we will supress warnings from code within node_modules and v24 will probably not have the warning as it should be stable by then."

Then why bother with the warning? It's lit up my server code like crazy, I didn't ask for this. If it's so experimental shouldn't it be an opt-in flag for now?

[joyeecheung]

It's lit up my server code like crazy

Is the server code running multiple processes/workers? This should only be emitted once per process/worker.

If it's so experimental shouldn't it be an opt-in flag for now?

It was previously behind a flag. The standard graduation process of an experimental feature is:

1. Make it opt-in behind a flag (on v22 for this feature, until we backport the unflagging)
2. Unflag it but emit a warning when it's used (on v23 for this feature)
3. Remove the warning but keep the experimental status (likely v24 for this feature)

For odd-number releases, which are usually more edgy and less used in production, it's common to expect more experiments being carried out and more warnings being emitted. You can consider using the even-numbered LTS if stability is a priority, or if you must use v23, you could use the --disable-warning=ExperimentalWarning flag to disable it.

[cchangwen]

process.removeAllListeners('warning').on('warning', err => {
    if (err.name !== 'ExperimentalWarning' && !err.message.includes('experimental')) {
        console.warn(err)
    }
})