Discussion: An ESM-first Node

[parrotsmod]

I know Node.js relies on CJS (src/node.cc, lib/internal/modules/cjs/loader.js, etc.) a lot but i think it might be useful to have a branch (not for merging into main) named no-commonjs where CommonJS is removed and Node is ESM-only. Could be a playground to test ESM-only workflows.

Node's main branch would stay untouched, so CJS compatibility would be kept.
If you'd like, we could make a fork instead based on Node.js 22.19.

[joyeecheung]

I think it might be very difficult to keep that branch in sync with the main branch, because the ESM loading and CommonJS share a lot of common bits (resolution logic, loading etc.) that are constantly being refactored and optimized, and they invoke each other for require(esm) and import cjs. So to keep that branch in this repo means you will constantly submit PRs targetting that branch to fix it up, and count on people to review it.

The CommonJS reliance isn't really so much that Node.js itself relies on CommonJS, but:

1. Code in the wild (e.g. on npm registry) widely rely on being executed as CommonJS even if the original code is written in ESM. e.g. according to https://github.com/wooorm/npm-esm-vs-cjs/ at least >60% of the high impact npm packages must be executed as CommonJS, the number in reality might be much higher (>80%) given that the chart aggregates downloads across versions, and now-ESM-only packages may still get most of their downloads from old CommonJS versions, and that dual packages are commonly getting their CommonJS entrypoint picked at runtime. Also, many popular frameworks (e.g. Next.js) transpile user ESM code into CommonJS before giving it to Node.js to run - so removing CommonJS loading would pull the rug out from under their feet. Whenever you see import ... from './extension/less/path' from the documented examples of a framework, they almost certainly rely on faux-ESM i.e. ESM that gets transpiled into CommonJS to run.
2. Widespread monkey-patching of the CommonJS loader internals in the wild e.g. very popular packages like https://www.npmjs.com/package/pirates relies on this to function.

You could gauge the state of the ecosystem and the breakage from removing 1 and/or 2 without touching Node.js core though. Using module.registerHooks you can throw whenever the format is detected to be commonjs to test breaking 1, and you can delete properties/prototype properties from require('module').Module or stub them with methods/accessors that throw to gauge 2. Although since it's already well known that 1 and 2 are large-scale issues, it probably goes without testing that if the goal is to migrate away from CommonJS, these known high-impact packages and frameworks need to stop doing 1 and 2 first before you can really see "what remains to get rid of CommonJS in Node.js".

[ljharb]

What would be the value of a build of node that can't ever work for the vast majority of applications?