module: drop support for extensionless files in ESM

[GeoffreyBooth]

This PR removes support for extensionless files in ES module contexts, per discussion in #31388 (comment). The current ESM implementation that shipped in 12.0.0 supported extensionless files only as main entry points to the Node process, e.g. node extensionless-file, and not via import; support for extensionless files in import was added only last month, in #31021. This PR reverts that one, and goes further to drop support for extensionless files as main entry points. The docs are also updated.

The prior support for extensionless main entry files was there as part of supporting bin files. As a practical matter, the “empty string” extension was designated as ES module JavaScript (equivalent to .mjs) within a "type": "module" scope. This is problematic for adding future support for extensionless files of other formats, such as WASM/WASI.

In the interest of preserving design space for such future support, this PR makes all extensionless files unknown (and therefore throwing) to the ESM loader. Another solution besides #31021 or the implementation’s earlier special casing of extensionless main entry points will need to be found for configuring Node’s ES module loader on how to treat extensionless files of varying formats.

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• documentation is changed or added
• commit message follows commit guidelines

cc @nodejs/modules-active-members

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/28494/

[guybedford]

Note that it is still possible to require extensionless files with this PR though:

require('./file/without-extension');
import('./file/without-extension');

In order to disallow CommonJS execution from allowing ES module imports, we should add an extension filter to the "pre-emptive caching" at https://github.com/nodejs/node/blob/master/lib/internal/modules/cjs/loader.js#L1072.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/28495/

[GeoffreyBooth]

Note that it is still possible to require extensionless files

To be clear, I think he means that once an extensionless file has been required, then import of that file will succeed when it shouldn’t, because of this preemptive caching. I think fixing that should be its own PR.

[aduh95]

To be clear, landing this PR means node ./bin/js-file-without-extension will be treated as CJS, no matter the package.json's type value, correct?

[GeoffreyBooth]

To be clear, landing this PR means node ./bin/js-file-without-extension will be treated as CJS, no matter the package.json's type value, correct?

No. If it's in a type: module scope, an error will be thrown.

If that's your situation, you could create a ./bin/package.json containing type: commonjs, and then the extensionless file in ./bin will be treated as CommonJS and become executable.

[bmeck]

LGTM, this alleviates prior concerns of edge cased behavior and solves the problem of removing edge cases that caused #31021 to be seen as a fix by taking the alternate route. Historically when behavior lacks consensus we remove controversial parts so this PR is likely the best route forward.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/28499/

[jkrems]

I'm a bit bummed that this will mean that self-contained binaries at known locations will be stuck with CommonJS or symlinks forever. But not bummed enough to block this. :)

[GeoffreyBooth]

this will mean that self-contained binaries at known locations will be stuck with CommonJS or symlinks forever.

Not forever, just until we find an alternative solution. 😄 There are options.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/28514/

[GeoffreyBooth]

CI: https://ci.nodejs.org/job/node-test-pull-request/28514/

CI is green.

[GeoffreyBooth]

Landed in dc90f92...c692568

[Ryuzaki42]

What about .ts as file extension? I'm trying to import some typescript module w/o .js files

node --loader ts-node/esm --experimental-specifier-resolution=node src/index.ts

and got

TypeError [ERR_INVALID_RETURN_PROPERTY_VALUE]: Expected string to be returned for the "format" from the "loader getFormat" function but got type object.
    at new NodeError (node:internal/errors:278:15)
    at Loader.getFormat (node:internal/modules/esm/loader:111:13)
    at Loader.getModuleJob (node:internal/modules/esm/loader:231:20)
    at ModuleWrap.<anonymous> (node:internal/modules/esm/module_job:58:21)
    at async Promise.all (index 1)
    at link (node:internal/modules/esm/module_job:63:9)