[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?

• [X] I have searched the existing issues

This issue exists in the latest npm version

• [X] 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:

• https://github.com/debug-js/debug/issues/975
• https://github.com/nodejs/node/pull/55338#issuecomment-2411753894
• https://github.com/nodejs/node/pull/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 https://github.com/nodejs/node/issues/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)

[avivkeller]

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

[MikeMcC399]

@RedYetiDev

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

You're right! https://github.com/npm/cli/blob/780afc50e3a345feb1871a28e33fa48235bc3bd5/package.json#L113

where [email protected] and above is pure ESM

• As identified by @ljharb in https://github.com/debug-js/debug/issues/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 https://github.com/debug-js/debug/issues/975 needs to be resolved by debug.

[MikeMcC399]

• To test, I downgraded to [email protected] prior to PR https://github.com/npm/cli/pull/6556 in [email protected]

npm install [email protected] -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 https://github.com/nodejs/node/pull/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.

[LitoMore]

@SparK-Cruz The workaround could be to switch to another package manager, but that's beside the topic.

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

• https://github.com/chalk/supports-color/pull/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)

[wellwelwel]

Although supports-color has no interest in supporting CommonJS (and it's fine) and I fully agree with @ljharb about the AUR problem, I'm wondering about an alternative:

• A completely independent package with supports-color as its only and direct dependency, extending supports-color support to CommonJS (nothing else).

The advantages would continue in the same way as in my previous comment:

• [x] It wouldn't overload the supports-colors maintainers to demand support for something that was intentionally removed.
• [x] This wouldn't be a fork, but an extension of the official project.
  • [x] As it would be just an extension, it would always be updated along with the official project in future versions.
  • [x] The official project code itself would be used by the end user, not any additional extension code.
• [x] Node.js could keep the warning message for an experimental feature.
• [x] It wouldn't need to change any logic in debug or npm/cli (just changing the dependency).
• [x] And probably, the most important, I believe that this would fully respect the supports-color maintainers.

As a natural note, I would be pleased to maintain support for this extension, as well as invite the maintainers of the official project to have commit and publish privileges (if they so wish).

It would be great if you could give some feedback.

---

As a simple proof of concept, I already use this solution locally:

---

[!NOTE] Looking at both debug and npm/cli projects, the only effective way out that doesn't seem like a workaround or temporary solution (for me), would be for both to be updated to a major version using ES Modules, as well as supports-color. Alternatively, assuming this "incompatibility" until a future version of Node.js (where this functionality would no longer be experimental).

Also, trying to force an old version of supports-color, which has already been declined by the npm/cli team in https://github.com/npm/cli/pull/7887#issuecomment-2450496361.

In advance, apologies if I sounded rude with this note, that's not my intention 🤝

There are no bugs or actual changes to the supports-color's source code and that's what makes this idea possible, since it would be just a complement (extension).

In this note, I'm also considering the recent https://github.com/debug-js/debug/issues/975#issuecomment-2454538059.

[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 https://github.com/debug-js/debug/issues/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.

[planetarquasar]

Any update on this about the fix? Cannot build the Laradock because of this bug. During the build stuck on this progress:

 => => # 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)
 => => # (node:3567) ExperimentalWarning: CommonJS module /home/laradock/.nvm/versions/node/v23.1.0/lib/node_modules/npm/node_modules/debug/src/node.js is loading ES Module /home/laradock/.nvm/versions/node/v23.1.0/lib/node_modules/npm/n  => => # ode_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)

[ljharb]

@planetarquasar those are just log messages, it shouldn't interfere with a build process. you can set NODE_OPTIONS='--disable-warning=ExperimentalWarning', though, and suppress them.

[planetarquasar]

Where should I put this?

[ljharb]

in your environment - it's an environment variable. Happy to help with further questions, but let's please not continue pinging people by commenting on this issue :-)

(npm folks, feel free to hide some of these tangents as off topic)

[gba-foundever]

For information, this 'WARNING' was make my yoeman installation not working with issue: https://github.com/yeoman/yeoman/issues/1778

putting export NODE_OPTIONS='--disable-warning=ExperimentalWarning' in bash removed the WARNING and the issue