I’m not sure I understand well but it looks like if the use cases you created exists since you want…
Nicolas Froidure

I must have misunderstood since your example doesn’t export anything.

> But my suggestion is really to take CommonJS module as what they are, a JavaScript script that exports an object (module.exports). This is why the `import {require} from ‘node:commonjs’; // bikeshed` line of your example was a const definition destructuring the exported object of the awaited async module load.

In order for the await style of deferring the value to work would require a top level await to be available as CJS might throw and deferring that to the event loop would not be catchable. Same is true for ESM, but ESM has no catching mechanism for this. https://docs.google.com/presentation/d/1xZILfv5WeUBKyQ9s1w8zArNgzTMGRFQXyRseSskjcjw/view has some details on the differing timing and error handling going on.

> The idea is to first load all CommonJS module, with a one object export shape and then load every ES6 modules.

This violates order of evaluation and removes predictability. import "foo";import "bar" would execute bar first if it was CJS.

This also requires “hoisting” inner modules out of subgraphs in order to evaluate before the graph which imported the subgraph. That doesn’t work for circular dependencies since they are tied to their dependent graph.

> That said, monkey patching `System.import` could be monkey patched to wrap CommonJS modules instead of transpiling them a priori as i suggested before. It would give a chance to add all the constant added to modules by NodeJS like `__dirname`.

System.import is not the proposal for dynamic imports import() is https://github.com/tc39/proposal-dynamic-import which is syntax and cannot be patched since it is directly in the VM.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.