[v25.7] yargs v17 compatibility issue

Version

v25.7.0

Platform

Microsoft Windows NT 10.0.26200.0 x64

Subsystem

No response

What steps will reproduce the bug?

npm i yargs@17.7.2
"require('yargs/yargs')" > 1.cjs
node 1.cjs

How often does it reproduce? Is there a required condition?

always

What is the expected behavior? Why is that the expected behavior?

no errors

What do you see instead?

file:///F:/node-yargs/node_modules/yargs/yargs:3
const {applyExtends, cjsPlatformShim, Parser, Yargs, processArgv} = require('./build/index.cjs')
                                                                    ^

ReferenceError: require is not defined in ES module scope, you can use import instead
    at file:///F:/node-yargs/node_modules/yargs/yargs:3:69
    at ModuleJobSync.runSync (node:internal/modules/esm/module_job:534:37)
    at ModuleLoader.importSyncForRequire (node:internal/modules/esm/loader:366:47)
    at loadESMFromCJS (node:internal/modules/cjs/loader:1628:24)
    at Module._compile (node:internal/modules/cjs/loader:1793:5)
    at Object..js (node:internal/modules/cjs/loader:1951:10)
    at Module.load (node:internal/modules/cjs/loader:1532:32)
    at Module._load (node:internal/modules/cjs/loader:1334:12)
    at wrapModuleLoad (node:internal/modules/cjs/loader:255:19)
    at Module.require (node:internal/modules/cjs/loader:1555:12)

Node.js v25.7.

Additional information

I'm not sure if this is a Node.js issue, because yargs uses a file without an extension as the entry point.

Ref #61600

@joyeecheung

The problem is that yargs expects extensionless files to be interpreted as CommonJS, rather than using the disambiguation process that Node.js uses for .js files based on package.json#type.

The new Node.js behavior is not wrong, but if it's not compatible with a package as widely used as yargs there might be an alternative solution. Maybe Node.js should always run the syntax-based detection on extensionless files (idea from @joyeecheung)? "we do not know whether this file is .js,.mjs, or .cjs, so we don't even know if we should look at package.json#type".

We do define this behaviour,¹ so I think this counts as a regression.

By default, Node.js will treat the following as CommonJS modules:

Files with an extension that is not .mjs, .cjs, .json, .node, or .js (when the nearest parent package.json file contains a top-level field "type" with a value of "module", those files will be recognized as CommonJS modules only if they are being included via require(), not when used as the command-line entry point of the program).

https://nodejs.org/docs/v25.7.0/api/modules.html#enabling ↩

Looks like it's a regression - though somehow the documentation is claiming something that is not part of the test suite, so it could also be a documentation bug.

(Now looking at it the docs are full of bugs re. loader internals, because CJS can be loaded by ESM loader and ESM can be loaded by CJS loader, and in the former case, if module.register used, there is even the funny quirk that it will use partial ESM resolution for CJS, and these have existed for years)

pin node 25 to 25.6

Re the above point from the docs as captured by @Renegade334: the point before it explicitly mentions “without an extension”, whereas this point mentions “with an extension that is not $list”. So it can be argued that this file yargs, without an extension, is not covered by that point.
Perhaps noteworthy because the code in GH-61600 is for path.extname(filename) === ''

Pin node version due to yargs compatibility issue

pin node 25 to 25.6 (#4600)

Pin node version to 25.6.1

Homebrew downstream confirmation from Node 25.7.0 rollout:

Node bump PR: node 25.7.0 Homebrew/homebrew-core#269249
Failing regression jobs:
- https://github.com/Homebrew/homebrew-core/actions/runs/22557136565/job/65336577807 (marp-cli)
- https://github.com/Homebrew/homebrew-core/actions/runs/22557140532/job/65336586655 (quint)

Both fail with:

ReferenceError: require is not defined in ES module scope
.../node_modules/yargs/yargs:3
Node.js v25.7.0

Local bottle repro on macOS arm64 matches (marp --version, quint --version).

For mitigation, Homebrew temporarily pinned these formulae to node@24 pending upstream compatibility:

build: pin Node.js to v24 (LTS) to bypass nodejs/node#61971

module: fix extensionless CJS files in type:module packages

module: fix extensionless CJS files in `"type": "module"` packages

25.8.1 is out with a fix

25.8.1 is out with a fix

fixed via #62083

Revert "Pin Node.js to 25.6" (#22188)

doc: remove extensionless CJS exception for type:module packages

Revert "Pin Node.js to 25.6" (#22188)

This is still broken in 26.7.0. What's the workaround?

This is still broken in 26.7.0. What's the workaround?

yargs/yargs#2509 (comment)

Fix Node.js 26 CI failure: yargs/mocha ESM incompatibility (issue #73)

Navigation Menu

Repository navigation

[v25.7] yargs v17 compatibility issue #61971

Version

Platform

Subsystem

What steps will reproduce the bug?

How often does it reproduce? Is there a required condition?

What is the expected behavior? Why is that the expected behavior?

What do you see instead?

Additional information

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[v25.7] yargs v17 compatibility issue #61971

Description

Version

Platform

Subsystem

What steps will reproduce the bug?

How often does it reproduce? Is there a required condition?

What is the expected behavior? Why is that the expected behavior?

What do you see instead?

Additional information

Activity

nicolo-ribaudo commented on Feb 24, 2026

nicolo-ribaudo commented on Feb 24, 2026

Renegade334 commented on Feb 24, 2026

Footnotes

joyeecheung commented on Feb 25, 2026

wooorm commented on Feb 26, 2026

chenrui333 commented on Mar 2, 2026

aduh95 commented on Mar 11, 2026

jkowalleck commented on Mar 11, 2026

jdmarshall commented on Aug 5, 2026

Renegade334 commented on Aug 5, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions