I must have misunderstood since your example doesn’t export anything.
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.