debug causes npm to always issue an experimental ESM warning in node 23

[ljharb]

Specifically,

debug/src/node.js

Line 32 in bc60914

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

is triggering it. See also nodejs/node#55338 (comment) and nodejs/node#55397.

I'm not sure the best solution here. One is to use optional peer deps to force supports-color to be < 9; another is to do monkeypatching shenanigans around that require to suppress the experimental warning; I'm sure there's more.

[joyeecheung]

The warning can also be temporarily disabled using process.noDeprecation = true (it's kind of an abuse because it's an experimental warning, not a deprecation warning, and it's kind of a bug that it affects the experimental warnings, but hey the bug is out there already). A slightly saner solution can be checking whether process.version starts with v23 (the warning will be restricted to code not coming from node_modules on v22, and will probably be gone by 24).

[MikeMcC399]

supports-color@9.0.0, released in Apr 2021, was the first version to use pure ESM.

This issue affects any project where supports-color >= 9.0.0 (ESM only) is installed together with debug. It is not restricted to npm.

For instance, on Ubuntu 24.04.1 LTS, Node.js 23.0.0, npm 10.9.0, executing the following:

git clone https://github.com/cypress-io/github-action
cd github-action
npm ci
node src/ping-cli.js https://example.cypress.io

not only shows the ExperimentalWarning from npm ci, it also shows the warning from

node src/ping-cli.js https://example.cypress.io

which is not using npm at all:

$ node src/ping-cli.js https://example.cypress.io
pinging url https://example.cypress.io for 30 seconds
(node:5900) 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)

https://github.com/cypress-io/github-action is configured with supports-color@9.3.1, i.e. a pure ESM version.

[ljharb]

@MikeMcC399 however, it'd only trigger on projects that require that version, which virtually nobody would do, except in this package's case where it's treated like an implicit optional dep - requiring < 9, and importing any version, wouldn't trigger the warning.

[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

[Qix-]

use optional peer deps

This is probably fine; I don't think that was around when I implemented the optional dependency stuff. PR welcome and I'll cut a patch release ASAP (especially if it's within the next 48 hours, otherwise might be after Nov 16th at some point. Some last minute traveling happening for urgent reasons. Ping me here if it falls through the cracks).

[wellwelwel]

@Qix-, first of all, thanks for your attention to this issue.

I would really appreciate it if you could take a look at npm/cli#7857 (comment), since it would directly implicate this project and, naturally, npm/cli (in a good way).

I can't say what the community thinks about this yet, but it's a solution that seems both user-friendly and easy to implement (locally, everything is practically ready), plus that wouldn't overload the team of any of the involved projects (debug, supports-color, and npm/cli).

[Qix-]

@stefee kindly submitted a PR, but the regressions stated here are a bit bothersome.

The only other "correct" alternative is to switch to ESM-only and use import, but I'd imagine that doesn't really solve problems people are facing today.

---

There's a less-nice alternative. Start without any extended color support, fire off an async import() and then once it completes retroactively enable extended color support. The first few log messages will have the basic colors but switch later on. I don't know how terrible of an idea that is, though.