[v25.7] yargs v17 compatibility issue

[liuxingbaoyu]

Version

v25.7.0

Platform

Microsoft Windows NT 10.0.26200.0 x64

Subsystem

No response

What steps will reproduce the bug?

1. npm i yargs@17.7.2
2. "require('yargs/yargs')" > 1.cjs
3. 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.

[nicolo-ribaudo]

Ref #61600

[nicolo-ribaudo]

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".

[Renegade334]

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

Footnotes

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

[joyeecheung]

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)