ESM should require file extensions

🐛 Bug Report

import t from './file';
import d from './directory/'

These should both fail to resolve, but since we use the same resolver as for CJS, it doesn’t, and the import will work while it would have failed at runtime. This is also the case for dynamic imports.

This might need some support in resolve whenever they add support for ESM? https://github.com/browserify/resolve/issues/222

Place where we call resolve in jest: https://github.com/facebook/jest/blob/c024dec130d9914dcc3418ea74c26f667db3dbfa/packages/jest-runtime/src/index.ts#L395-L398 https://github.com/facebook/jest/blob/c024dec130d9914dcc3418ea74c26f667db3dbfa/packages/jest-runtime/src/index.ts#L423

Node docs: https://nodejs.org/api/esm.html#esm_mandatory_file_extensions Node issue for better errors: https://github.com/nodejs/node/issues/30603

[SimenB]

--experimental-specifier-resolution=node is the flag. And yeah, we’d need to keep the logic around for that case… Not sure how to best detect if it has been passed. It’s not present in process.argv so we might need to have our own option for this 🙁

[cspotcode]

Bundlers are effectively a runtime target. I simply mean that, in terms of the TS team’s decision-making, it is technically valid ESM, which is why they’re supporting it. It’s not merely a backwards-compat issue. A lot of the ecosystem’s problems tend to get blamed on TS, when it’s actually TS playing along with the ecosystem’s desire to be custom at every turn.