Skip to content

[WIP] Support requiring .mjs files

This implements the ability to use require on .mjs files, loaded via the esm loader, using the same tradeoffs that top level await makes in esm itself.

What this means: If possible, all execution and evaluation is done synchronously, via immediately unwrapping the execution's component promises. This means that any and all existing code should have no observable change in behavior, as there exist no asynchronous modules as of yet. The catch is that once a module which requires asynchronous execution is used, it must yield to the event loop to perform that execution, which, in turn, can allow other code to execute before the continuation after the async action, which is observable to callers of the now asynchronous module. If this matters to your callers, this means making your module execution asynchronous could be considered a breaking change to your library, however in practice, it will not matter for most callers. Moreover, as the ecosystem exists today, there are zero asynchronously executing modules, and so until there are, there are no downsides to this approach at all, as no execution is changed from what one would expect today (excepting, ofc, that it's no longer an error to require("./foo.mjs").

As of right now, this is missing:

  • Support for "type": "module" in the cjs loader. (where did that go? I thought we already had something that did that internally - getPackageType or something?)
  • New tests (I have no idea how to write tests for node, help appreciated)
  • Speculative integration tests for https://github.com/nodejs/node/pull/30370 - the code is already written assuming ModuleWrap.evaluate may eventually return a promise.

Merge request reports

Loading