Tracking issue: require(esm)

[joyeecheung]

Before it's unflagged

• Figure out default export interop with transpilers, either adding __esModule to required ESM on our end (module: add __esModule to require()'d ESM #52166), or transpilers update themselves to check the result returned by require():
• conditional exports for module, regardless of whether it's loaded by require or import. Something like module which is recognized by Webpack and Rollup would be good (maybe this doesn't need to block unflagging, but should be done before stablization) module: implement the "module" exports condition #54648
• Some marker to customize the default exports returned by require(esm) module: __cjsModule on ESM CJS wrapper and in require ESM #53848
• Move experimental warning to where require() is actually handling a ESM

Before it is promoted to be stable:

• Implement detection module: support ESM detection in the CJS loader #52047
• Support module customization hooks doc: add synchronous hooks proposal loaders#198

Nice-to-haves:

• Add API for dumping or inspecting the consolidated CJS and EJS module graph #52180
• Provide some mechanism to conditionally and synchronously import modules (or just builtins) from ESM #52599

[GeoffreyBooth]

@nodejs/loaders

[jakebailey]

I just wanted to note it here, but it would be super super awesome if (once stable) this were backported to Node 20/22 or even Node 18 if still in support. I'd love to be able to propose a change to switch TypeScript to ESM (given I have it working without breaking CJS consumers), but the time horizon of Node 22 being the oldest supported version is pretty daunting.

It also seems like there is a hacky way using multiple entrypoints that could allow for TS to grab Node's builtins conditionally without #52599/#52762, though none of that is possible without require(ESM), of course.

Even without TypeScript's use case, I think the feature itself is a really important one for the ecosystem. Backporting would really make ESM changeovers a lot less painful.

[Andarist]

IIRC from some Twitter threads - there is a plan to backport this once the feature stabilizes.

[joyeecheung]

Regarding the conditional exports, @guybedford suggested to implement just the module condition that Rollup and Webpack already recognize. I have a WIP but need to do some testing which involves many combinations of test cases 😵‍💫 but will also do some npm crawling to see if it can be picked up/is in conflict with any existing popular packages.

[GeoffreyBooth]

@guybedford suggested to implement just the module condition that Rollup and Webpack already recognize.

The module top level field, or within exports?

Personally I think require-module makes more sense, as it would complement the existing require and import keys that Node supports.

[joyeecheung]

Opened PR for "module" in #54648

Personally I think require-module makes more sense, as it would complement the existing require and import keys that Node supports.

If we are starting from scratch, yes, but then the "module" condition has already been adopted by bundlers that support require(esm) in the wild, so it seems better to go along with the existing convention. See https://gist.github.com/sokra/e032a0f17c1721c71cfced6f14516c62