TC39 Module Harmony
2022-07-29
plaintext logs
prev next
source on github
03:23
<sis3020>
Come play the top mmorpg https://feetporn.win/ dmcbqw play soon
04:57
<Jack Works>
I read the request as one to find a solution to the problem that named imports can’t trigger an export accessor, the way destructuring a module.exports can.
I don't think access a named import should trigger any kind of user code. That's not a good idea.
05:04
<Jack Works>
Moddable has also brought up sync loading as an important concern for them

I think maybe XS can implement Promise and dynamic import() in a way that,

  • Promise constructor is not constructable
  • No Async Function
  • dynamic import or Module#import() will resolve the Promise in sync.
  • Promise.then/catch/finally is not callable

For the given constraint above, the top level await await import("./some-file.js") will looks almost sync (maybe there is some ticking problem?)

06:37
<Kris Kowal>
Perhaps I can ask naugtur to put together an example cjs virtual module source. I believe he may have adequately addressed Rob’s request in Endo by linking CJS on the plane of default exports, which allows for lazy accessors
07:04
<Kris Kowal>

I think maybe XS can implement Promise and dynamic import() in a way that,

  • Promise constructor is not constructable
  • No Async Function
  • dynamic import or Module#import() will resolve the Promise in sync.
  • Promise.then/catch/finally is not callable

For the given constraint above, the top level await await import("./some-file.js") will looks almost sync (maybe there is some ticking problem?)

I think this will look more like Module#importNow() for Moddable. It is possible to have both Module#import() and Module#importNow(), where the latter just throws if the transitive dependencies have not yet been loaded. For parity with Compartment, that would entail having Module#load(), which would just do the load phase, driving the importHook but not linking, initializing, or executing, such that Module.prototype.import = async () => { await this.load(); return this.importNow(); }
11:16
<naugtur>

I've checked the current state of Endo and the act of creating a module instance doesn't trigger the getters. They're not triggered if the module is required either. Importing anything does trigger all the getters. But it looks like an oversight that needs a fix in layers above.

[edit] Looks like the above was interference from the testing method. I'm looking at an example of a getter on cjs exports that doesn't trigger the getter when default is imported.
It's not accessible as a named export though, which might be the whole point here.

14:34
<Kris Kowal>
I think it would be at least partially satisfying if CJS to CJS laziness were preserved. Lazy CJS to ESM would be at least possible if ESM just grabs the default. ESM to ESM laziness would be possible too, on the default. But lazy named imports are probably not in the cards. I think sync execution is a different kind of laziness that might give us parity for ESM but with a different mechanism. Deferred execution yet another.
14:38
<Kris Kowal>
And of course code splitting and tree shaking are both ESM native solutions in the same space. I’m a fan of linear progressive bundles: where the bundle has disjoint sub-bundles from a sequence of entrypoints.
14:40
<Kris Kowal>
Ten years ago, FaceBook did something similar for code delivery, but non-linearly. Their bundles attempted to predict common combinations, with minimal but nonzero overlap