module: support require()ing synchronous ESM graphs

[joyeecheung]

Summary

This patch adds require() support for synchronous ESM graphs under
the flag --experimental-require-module

This is based on the the following design aspect of ESM:

• The resolution can be synchronous (up to the host)
• The evaluation of a synchronous graph (without top-level await) is
  also synchronous, and, by the time the module graph is instantiated
  (before evaluation starts), this is is already known.

If --experimental-require-module is enabled, and the ECMAScript
module being loaded by require() meets the following requirements:

• Explicitly marked as an ES module with a "type": "module" field in
  the closest package.json or a .mjs extension.
• Fully synchronous (contains no top-level await).

require() will load the requested module as an ES Module, and return
the module name space object. In this case it is similar to dynamic
import() but is run synchronously and returns the name space object
directly.

// point.mjs
export function distance(a, b) { return (b.x - a.x) ** 2 + (b.y - a.y) ** 2; }
class Point {
  constructor(x, y) { this.x = x; this.y = y; }
}
export default Point;

// main.js
const required = require('./point.mjs');
// [Module: null prototype] {
//   default: [class Point],
//   distance: [Function: distance]
// }
console.log(required);

(async () => {
  const imported = await import('./point.mjs');
  console.log(imported === required);  // true
})();

If the module being require()'d contains top-level await, or the module
graph it imports contains top-level await,
ERR_REQUIRE_ASYNC_MODULE will be thrown. In this case, users should
load the asynchronous module using import().

If --experimental-print-required-tla is enabled, instead of throwing
ERR_REQUIRE_ASYNC_MODULE before evaluation, Node.js will evaluate the
module, try to locate the top-level awaits, and print their location to
help users find them.

Background

There were some previous discussions about this idea back in 2019 (e.g. #49450). I I didn't go through all of them, but in 2024 I believe we can agree that not supporting require(esm) is creating enough pain for our users that we should really deprioritize the drawbacks of it. A non-perfect solution is still better than having nothing at all IMO.

There was a previous attempt in #30891 which tried to support TLA from the start and thus needed to run the event loop recursively, which would be unsafe and therefore it was closed (synchronous-only require(esm) was brought up in #30891 (comment) but the PR didn't end up going that way). I have the impression that there were some other attempts before, but non active AFAIK.

This PR tries to keep it simple - only load ESM synchronously when we know it's synchronous (which is part of the design of ESM and is supported by the V8 API), and if it contains TLA, we throw. That should at least address the majority of use cases of ESM (TLA in a module that's supposed to be import'ed is already not a great idea, they are more meant for entry points. If they are really needed, users can use import() to make that asynchronicity explicit).

When I was refactoring the module loader implementation and touching the V8 Module API to fix other issues, this idea appears to be natural to me (since ESM is really designed to have this synchronocity in mind) and does not actually need that much work in 2024 (er, with some refactorings that I already did for other issues at least..), so here is another attempt at it.

Motivation

The motivation for this is probably obvious, but I'll give my take again in case there are unfamiliar readers: CJS/ESM interop would always be done on a best-effort basis and they should not be mixed if avoidable, but today the majority of the popular packages out there in the registry are still CJS. There needs to be an escape hatch for simple cases while the transition happens.

With require(esm), when a dependency goes ESM-only, it is less likely to be a breaking change for users as long as it's a synchronous ESM (with no top-level await), which should be the case most of the time. This helps package authors transition to ESM without worrying about user experience, or having to release it as dual module which bloats the node_modules size even further and leads to identity problems due to the duplication.

The design of ESM already ensures that synchronous evaluation and therefore interop with CJS for a synchronous graph is possible (e.g. see tc39/proposal-top-level-await#61), and we won't be alone in restricting TLA for certain features(e.g. w3c/ServiceWorker#1407 service workers on the web also disallows TLA) it would be a shame not to make use of that. Ongoing proposal like import defer could also help addressing the lazy-loading needs without breaking the synchronous aspect of ESM.

TODOs

There are still some feature interactions that this implementation doesn't handle (e.g. --experimental-detect-module or --experimental-loader or --experimental-wasm-modules). Some edge cases involving cycles probably would have undefined behaviors. I don't think this needs to handle interactions with everything (especially other experimental features) perfectly to land as a first iteration of an experimental feature. We can continue iterating on it while it's experimental.

[nodejs-github-bot]

Review requested:

• @nodejs/loaders
• @nodejs/startup
• @nodejs/test_runner
• @nodejs/vm

[github-actions]

The notable-change PRs with changes that should be highlighted in changelogs. label has been added by @RafaelGSS.

Please suggest a text for the release notes if you'd like to include a more detailed summary, then proceed to update the PR description with the text or a link to the notable change suggested text comment. Otherwise, the commit will be placed in the Other Notable Changes section.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/57598/

[GeoffreyBooth]

Before we get into the technical details, I just want to give a heartfelt THANK YOU to @joyeecheung for taking this on, and express my awe of her brilliance in figuring out how to achieve it. require of ESM has been something that we’ve been discussing off and on for years, with dreams of someday figuring out how to achieve it in a shippable way, so if this PR can result in that then we will all be very grateful; and this new functionality will be transformative for module authors, who will be able to write libraries with less worry around interoperability issues.

[GeoffreyBooth]

• currently loader hooks are ignored in this path, because they already don’t affect require() anyway

I think the hooks do affect require, since #47999. I don’t think wiring them up to this needs to be a blocker for landing this PR, but if it’s not difficult perhaps we could either warn or error if hooks are registered when a require of an ES module occurs.

WASM support

import of Wasm is still experimental and there’s no timeframe for that changing (we were waiting on spec changes the last I recall) so I wouldn’t worry about this.

.cjs exclusion, directory resolution handling

What does this mean? Doing the extension searching for .cjs and/or .mjs in the filename? I wouldn’t worry about that for this PR; anyone doing require of a .cjs file needs to add the .cjs extension today, so it would be expected to need to continue to specify it; and likewise for .mjs.

[ShogunPanda]

I LOVE this idea. It will simplify so many things. Let's keep going with it.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/57603/

[joyeecheung]

I think the hooks do affect require, since #47999. I don’t think wiring them up to this needs to be a blocker for landing this PR, but if it’s not difficult perhaps we could either warn or error if hooks are registered when a require of an ES module occurs.

They only affect the require() in imported CJS modules, not the required ones. I think it's not a good idea to let the loader hooks affect require() the way it currently works - by spawning a separate thread to make it synchronous, it leads to similar concerns raised previously about supporting TLA in the fallback, then we are back to square one (and, unlike import syntax which is static and handled before module evaluation, require() is a regular function that can be called anywhere, so making it block on a new thread that can run any JS makes things even more complicated than TLA). Someone who thought this separate-thread behavior applies everywhere already raised this to me, I think we are lucky at least that the CJS require is unaffected and not beyond saving. For this PR, I think we can just ignore hooks when the fallback is enabled, and warn about it. (On a side note, I noticed that the require() added by #47999 is cutting corners e.g. not respecting policy...).

What does this mean? Doing the extension searching for .cjs and/or .mjs in the filename?

It means I don't know what happens when this happens, and there are not yet any test for it.

[benjamingr]

Big +1 on the idea and I think bun shows this is feasible and users like it.

[marco-ippolito]

@joyeecheung if you are interested I guess we can backport this to v20 (only 2 out of 3 commits landed on v20x)

[joyeecheung]

If it doesn't land cleanly I can prepare a backport - there are a couple of bug fixes that should be backported together too.

[marco-ippolito]

If it doesn't land cleanly I can prepare a backport - there are a couple of bug fixes that should be backported together too.

yes thanks I think this has been baking for lts enough

[joyeecheung]

Note: it's not landing cleanly because #50322 and #51999 are not yet on v20.x. #51999 is technically not non-breaking but also I imagine the breakage is tiny - only printing some warnings when it's about to quit with unsettled TLA, though I'd let the releasers decide wether it's okay to backport it to v20.x. For now I'll just prepare a backport with non-risky patches.

[joyeecheung]

It seems backporting the detection-related patches would be somewhat problematic if #50322 isn't backported first (then all the module type detection logic would need to be rewritten to match the old internal API, which would make backporting #50322 later even harder). I'll try to just backport the require(esm) part and drop detection for now until #50322 is backported.

[joyeecheung]

#52868 depends on #52058 which depends on #51758 which depends on a new V8 API that's not on v20.x. I guess the safest way to backport the chain is to add a variant of #51758 which use the old V8 API, that would be slow but at least allow us to avoid conflicts of future patches depending on the utility...

[joyeecheung]

Opened #53500

[mikegwhit]

i just want to add my thanks for this PR, looking forward or greatly hoping for this to mature past an experimental flag!!! i'm not on either team (ESM or CJS) but i am on the team of not (for political or ideological reasons) breaking backwards compatibility, so this is great!