[BUG] ExperimentalWarning: Support for loading ES Module in require() is an experimental feature and might change at any time

[alexsch01]

Is there an existing issue for this?

• I have searched the existing issues

This issue exists in the latest npm version

• I am using the latest npm

Current Behavior

When installing any package with Node.js v23.0.0 and npm v10.9.0, I get the following warning

(node:10424) 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)

Expected Behavior

No response

Steps To Reproduce

No response

Environment

• npm: 10.9.0
• Node.js: 23.0.0
• OS Name: Windows 10 22H2
• npm config: default

; node bin location = C:\Program Files\nodejs\node.exe
; node version = v23.0.0
; npm local prefix = C:\Users\$USER\Downloads\test
; npm version = 10.9.0
; cwd = C:\Users\$USER\Downloads\test
; HOME = C:\Users\$USER
; Run `npm config ls -l` to show all defaults.

[shadowspawn]

This is triggered by the experimental --experimental-require-module flag being made the default behaviour in Node.js 23. Related links:

• debug causes npm to always issue an experimental ESM warning in node 23 debug-js/debug#975
• 2024-10-16, Version 23.0.0 (Current) nodejs/node#55338 (comment)
• module: unflag --experimental-require-module nodejs/node#55085

[MikeMcC399]

It's not necessary to install anything with npm to provoke the ExperimentalWarning.

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

Ubuntu 24.04.1 LTS
Node.js v23.0.0
npm 10.9.0 (latest)

Same ExperimentalWarning for many other CLI commands from https://docs.npmjs.com/cli/v10/commands:

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

[MikeMcC399]

• See also discussion in Can we supress the new experimental warning from the new default require(esm) setting? nodejs/node#55417

[MikeMcC399]

Setting the environment variable NODE_OPTIONS='--trace-warnings' produces some trace output.

$ NODE_OPTIONS='--trace-warnings' npm view npm view
(node:6610) ExperimentalWarning: Support for loading ES Module in require() is an experimental feature and might change at any time
    at emitExperimentalWarning (node:internal/util:273:11)
    at loadESMFromCJS (node:internal/modules/cjs/loader:1388:5)
    at Module._compile (node:internal/modules/cjs/loader:1525:5)
    at Object..js (node:internal/modules/cjs/loader:1680:16)
    at Module.load (node:internal/modules/cjs/loader:1328:32)
    at Function._load (node:internal/modules/cjs/loader:1138:12)
    at TracingChannel.traceSync (node:diagnostics_channel:315:14)
    at wrapModuleLoad (node:internal/modules/cjs/loader:218:24)
    at Module.require (node:internal/modules/cjs/loader:1350:12)
    at require (node:internal/modules/helpers:138:16)

[RedYetiDev]

FYI the ESM being require()d is supports-color.

[MikeMcC399]

@RedYetiDev

FYI the ESM being require()d is supports-color.

You're right!

cli/package.json

Line 113 in 780afc5

"supports-color": "^9.4.0",

where supports-color@9.0.0 and above is pure ESM

• As identified by @ljharb in debug causes npm to always issue an experimental ESM warning in node 23 debug-js/debug#975 and relayed above by @shadowspawn , debug is using the following code to check on the availability of supports-color.

const supportsColor = require('supports-color'); 

where debug is effectively allowing an ESM version of supports-color to be installed and used:

  "peerDependenciesMeta": {
    "supports-color": {
      "optional": true
    }

So I guess the underlying issue debug-js/debug#975 needs to be resolved by debug.

[MikeMcC399]

• To test, I downgraded to npm@9.7.1 prior to PR fix: better color support detection #6556 in npm@9.7.2

npm install npm@9.7.1 -g

and there was no more warning under Node.js v23.0.0 from

npm view npm version

[MikeMcC399]

Under Node.js v23.1.0 the warning provides additional debugging information which confirms the previous analysis:

$ npm view npm version
(node:13088) ExperimentalWarning: CommonJS module /home/mike/n/lib/node_modules/npm/node_modules/debug/src/node.js is loading ES Module /home/mike/n/lib/node_modules/npm/node_modules/supports-color/index.js using require().
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

• Message enhancement through module: include module information in require(esm) warning nodejs/node#55397

[deleonjulio]

Out of nowhere, npm install and npm start doesnt work in my project. I have to downgrade my node version to make it work.

[MikeMcC399]

@deleonjulio

Out of nowhere, npm install and npm start doesnt work in my project. I have to downgrade my node version to make it work.

That sounds like a different issue. This issue is about an ExperimentalWarning only, where npm continues to work.

[SparK-Cruz]

What can we do other than rewrite everything between npm to debug, inclusive, in ESM?

[ljharb]

@SparK-Cruz you can't do anything, whatsoever. Only node, npm, or debug, can do something about it.

[SparK-Cruz]

@SparK-Cruz you can't do anything, whatsoever. Only node, npm, or debug, can do something about it.

@ljharb We can always open a pull request... if gets approved or not is another story. Worst case scenario I can fork it and add it to the AUR.

[ljharb]

@SparK-Cruz yes, a PR to debug would be a possible path forward.

Forking things to AUR without the consent of the maintainer doesn’t actually help the ecosystem, though, and it makes things worse for AUR users because they’re not really using the actual software.

[mantoni]

Hm, I think the cause of this is npm cli directly depending on a different major version of supports-color than chalk and debug. I tried downgrading to v7.x in #7887 and it fixes the problem and seems to work fine.

[wellwelwel]

I opened a PR with a really simple approach to fix it from supports-color side, by adding an automation to also export the index.js (ESM) to index.cjs. This allows the supports-color to support both CommonJS, ES Modules and browsers, fixing the issue in both debug and npm/cli, and allowing Node.js to keep the experimental warning.

Also, no changes would be necessary either on the debug or npm/cli side (except maybe forcing an update to the new supports-color version, if approved).

• feat: support for CommonJS chalk/supports-color#156

---

EDIT: Unfortunately, supports-color's decision is in fact not to be compatible with CommonJS.

[damisparks]

I get this error on npm publish:

(node:85003) 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)
npm error code ENOENT
npm error syscall open

I was only able to publish by using node 22.

[ljharb]

@damisparks node v23.0.0 is broken, so you'd need to be on v23.1.0. The experimental warning would still occur, though.

[damisparks]

@ljharb After upgrading to v23.1.0 , I could publish.
I still see the experimental warning, as you said.

(node:19390) ExperimentalWarning: CommonJS module /Users/damisparks/.nvm/versions/node/v23.1.0/lib/node_modules/npm/node_modules/debug/src/node.js is loading ES Module /Users/damisparks/.nvm/versions/node/v23.1.0/lib/node_modules/npm/node_modules/supports-color/index.js using require().
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)

[jonkoops]

Considering the CLI targets Node.js versions that all support ESM, perhaps the easiest way to mitigate this issue is to start using ES modules instead of CommonJS? Is there any particular blocker that might prevent doing so?

[ljharb]

@jonkoops the issue occurs in debug, which is CJS, so npm using ESM would have no effect on it whatsoever.

[jonkoops]

@ljharb I see you already logged debug-js/debug#975 for that, thanks I'll follow the discussion there. Still, this would presumably also affect the CLI even if this debug itself was ESM, but just move the warning up the chain.

So my question still stands, would there be any technical reason the CLI itself could not be authored in ESM in terms of compatibility?

[ljharb]

Probably not? but there'd also be no concrete benefit, either - only a subjectively ideological one.