`node --loader` treats entrypoint as ESM when should be loaded as CJS

[cspotcode]

• Version: 14.1.0
• Platform: Ubuntu 19
• Subsystem: entrypoint handling

What steps will reproduce the bug?

mkdir empty-dir
cd empty-dir
echo '{}' > package.json
touch entrypoint
touch hooks.mjs
node ./entrypoint # <-- no error; no output; exit code 0
node --loader ./hooks.mjs ./entrypoint # <-- error that "" is not a recognized file extension by the default ESM loader

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

Always

What is the expected behavior?

./entrypoint is executed as a CommonJS module whether or not --loader is passed.

What do you see instead?

When --loader is passed, node always tries to load entrypoint scripts as ESM, ignoring that package.json wants the file to be treated as CJS. This does not happen when --loader is omitted, suggesting that this behavior is a bug.

"" is not a recognized file extension by the default ESM loader
(node:26067) ExperimentalWarning: --experimental-loader is an experimental feature. This feature could change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
internal/modules/run_main.js:54
    internalBinding('errors').triggerUncaughtException(
                              ^

TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension "" for /d/Personal-dev/@TypeStrong/ts-node-repros/empty-dir/entrypoint
    at Loader.defaultGetFormat [as _getFormat] (internal/modules/esm/get_format.js:65:15)
    at Loader.getFormat (internal/modules/esm/loader.js:113:42)
    at Loader.getModuleJob (internal/modules/esm/loader.js:244:31)
    at async Loader.import (internal/modules/esm/loader.js:178:17) {
  code: 'ERR_UNKNOWN_FILE_EXTENSION'
}

Additional information

#33223

[ljharb]

cc @nodejs/modules-active-members

[guybedford]

This sounds like a resolver bug to me in that extensionless files not inside of "type": "module" with no parent (is the Node.js main) should always be treated as CommonJS for resolver consistency.

@GeoffreyBooth this was likely disabled as a feature in your previous PR.

[guybedford]

Note the workaround is to write a loader that ensures the main is a CommonJS module.

The difficulty here is the getFormat separation.

I'd be open to getFormat having an isMain boolean in its context representing if it is the Node.js main entry point.

[GeoffreyBooth]

It's any unknown extension, not just extensionless files. Continuing from the steps above:

➜  mv entrypoint entrypoint.foo
➜  node --loader ./hooks.mjs ./entrypoint.foo
(node:97802) ExperimentalWarning: --experimental-loader is an experimental feature. This feature could change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
internal/modules/run_main.js:54
    internalBinding('errors').triggerUncaughtException(
                              ^

TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension ".foo" for /private/tmp/test/empty-dir/entrypoint.foo
    at Loader.defaultGetFormat [as _getFormat] (internal/modules/esm/get_format.js:65:15)
    at Loader.getFormat (internal/modules/esm/loader.js:113:42)
    at Loader.getModuleJob (internal/modules/esm/loader.js:244:31)
    at async Loader.import (internal/modules/esm/loader.js:178:17) {
  code: 'ERR_UNKNOWN_FILE_EXTENSION'
}

It seems that when loaders are enabled at all, the check for known/ESM-supported file extensions is run on the main entry point, regardless of format.

[cspotcode]

How is the main entrypoint intended to be resolved: via the CommonJS resolver or via the ESM resolver?

If an ESM file imports another file, then I know the ESM resolver is invoked. For require() I know the old CJS resolver is used. After resolution, the target file is classified as either ESM and CJS.

But I don't know the rules governing which resolver is used for the entrypoint. How do I control the choice of resolver for node invocations?

Am I supposed to be able to do node --loader http-esm-loader https://example.com/script.js?

[guybedford]

@cspotcode this function determines whether to use the ES module loader or CommonJS loader on startup - https://github.com/nodejs/node/blob/master/lib/internal/modules/run_main.js#L23.

Whenever you use the --loader flag it sets to use the ES module loader, which has exposed this bug since normally the ES module loader doesn't run extensionless files.

Making the main an exception in the CommonJS case (no type: module) seems like the appropriate fix for this bug.

[cspotcode]

@guybedford thanks for explaining. It would be nice to get this added to the docs. Otherwise, I think the safe assumption is that registering a custom loader is independent of node's CJS / ESM resolver selection.

https://nodejs.org/dist/latest-v14.x/docs/api/esm.html#esm_experimental_loaders

When hooks are used they only apply to ES module loading and not to any CommonJS modules loaded.