22:22
<Kris Kowal>
nicolo-ribaudo: I got a question from guybedford and want to confirm we’re on the same page: reflective import would advance the module to loaded but not to linked and its dependencies won’t be loaded.
22:23
<Kris Kowal>
I can easily imagine import(x, {reflect: true, state: 'linked'}) or some such would load transitive dependencies without initializing or executing.
22:27
<nicolo-ribaudo>
Right, it would not load it's dependencies.
However, I hope it will not just result in a ModuleSource but in something that contains all the info necessary to later load&link it's dependencies
22:30
<nicolo-ribaudo>
"would advance the module to loaded" -> Informally yes. Formally, it doesn't advance the module's state because the first state change happens when loading all its dependencies. It just makes us go from "I have nothing" to "I have a Module/ModuleSource"
22:30
<Kris Kowal>
I assume it would not be an observable optimization if the Module Record was born with a null pointer to the structs needed to advance past the loaded state.
22:34
<Kris Kowal>
We are in agreement about having a Module object and not just a ModuleSource but guybedford would like us to at least contemplate the alternative given that deferred await import(reflectedModule) doesn’t go as far as yulia’s proposing for deferred execution. I don’t think our current agreement precludes going farther and I think it’s compelling for code splitting, but it wouldn’t initialize a dependency on the stack of the first access of one of its exports.
22:36
<Kris Kowal>
In any case, I wanted to make sure about reflection being shallow since that’s important to Guy. It’s important to me too, since it’s possible to load a module that can’t advance to linked without a custom import hook.
22:37
<nicolo-ribaudo>
We are in agreement about having a Module object and not just a ModuleSource but guybedford would like us to at least contemplate the alternative given that deferred await import(reflectedModule) doesn’t go as far as yulia’s proposing for deferred execution. I don’t think our current agreement precludes going farther and I think it’s compelling for code splitting, but it wouldn’t initialize a dependency on the stack of the first access of one of its exports.
Yeah, we are not solving deferred execution.
I'm almost hoping we can have import.link(module) -> Promise and import.evaluateSync(module) 😬
22:38
<nicolo-ribaudo>
In any case, I wanted to make sure about reflection being shallow since that’s important to Guy. It’s important to me too, since it’s possible to load a module that can’t advance to linked without a custom import hook.
I'm 100% aligned with that. I have use cases for not loading the whole graph, and import reflection should be shallow.
22:39
<nicolo-ribaudo>
For JS, it's exactly like module { export * from "x" } which doesn't load the graph until the block is imported (except that reflection loads "x", this almost-equivalent-module-block doesn't)
22:40
<Kris Kowal>
Right, I expect module expressions to be shallow too.
22:40
<Kris Kowal>
Same reasons. They might be sent somewhere their linkage is possible even if that’s not local.