Why ERR_MODULE_NOT_FOUND happens after switching Node.js to ESM

ERR_MODULE_NOT_FOUND after switching Node.js to ESM often means the import path no longer resolves the same way it did under CommonJS or a bundler.

The first check is the exact file path in the emitted JavaScript, not only the TypeScript source. Node runs the built file, so a path that looked reasonable in src can point to the wrong place in dist. If TypeScript preserves import specifiers, the runtime may still see an extensionless import or a path that does not exist after compilation.

The second check is file extension. In native ESM, relative imports commonly need the extension that will exist at runtime, such as ./client.js rather than ./client. Bundlers and transpilers may accept extensionless imports, but Node’s runtime resolver can be stricter. Mixing those assumptions is a common source of confusion.

The third check is package type. A package.json with type: module changes how .js files are interpreted. A dependency or workspace package may also expose only certain entry points through exports. Importing a private internal path that used to work can fail once exports are enforced.

The fourth check is case sensitivity and deployment environment. A path that works on a case-insensitive local filesystem can fail on a Linux runner or container. The error message may look like a module format problem, but the actual issue can be one capital letter in a folder name.

A practical debug sequence is: run node on the built file, copy the failing import specifier, resolve it relative to that file, confirm the target exists with the exact case and extension, then inspect package.json type and exports. This is faster than changing module settings blindly.

Why ERR_MODULE_NOT_FOUND happens after switching Node.js to ESM

// COMMENTS

ON THIS PAGE