| 15:47 | <Kris Kowal> | I’ve been thinking about Luca Casonato’s proposal for ModuleSource and Module sharing access to private origin information and nicolo-ribaudo’s thought about how that would impact multiple-instantiation. It seems clear that it would not be possible for the host module hook to create more than one instance per url in this scheme. That would make it equivalent in utility to any HTML system where a Worker can be instantiated with a configured resolution behavior (like transferring the import map) and importing by URL specifier. |
| 15:47 | <Kris Kowal> | And, to emulate the behavior, new Module would need to support return-override if the ModuleSource had an already memoized physical location. I feel that’s an undesirable complication. |
| 15:49 | <Kris Kowal> | It would be good to review yulia’s idea for transferring modules between agents. It seems likely that it would imply fewer complications. |
| 16:02 | <yulia> | I would need to know more about the restrictions in terms of what we are virtualizing. I'm not at all confident in my comment the other day. I think my idea won't help here (which was sharing the import graph by passing it, otherwise falling back on the behavior that would be implemented by modulesource). I think there are other restrictions that would make that unacceptable. From a browser perspective, we don't allow multi-instantiating within the same loader. The spec allows it, but all browsers cache (and the spec is being updated to reflect this. I would need to understand a few concrete usecases for this. On the other hand, i can see a usecase for multi-instantiation with module unloading, one frustration we have is the inability to garbage collect a module after instantiation (after which point it is no longer used). We have an api for that internally. Regarding the shared module map: I can see this as making things more memory efficient and allowing us to just pull the sources that we need, in the configuration that we need, and re-run them. However, passing that between different contexts with dynamic import seems like it could be very complex and open up possibilities I haven't thought about. I think the most restricted case is the safest. We could also introduce a distinction between the dynamic import links and the static ones, and allow sharing of only static links, meaning that dynamic import links would reconstruct, or would point to a sub-tree that is all static and preloaded. but like i said -- this seems verrrry complex |
| 16:09 | <Kris Kowal> | yulia: Caridy’s proposing adding a local map from specifier to module instance on each module instance that is intended to unlock multi-instancing, including hot reload, test scaffolds, mocking, &c. Having module instances also unlocks the ability to assemble a module graph without executing it, which is useful for bundling, building a fully-specified import map, &c. https://tc39.es/proposal-compartments/0-module-and-module-source.html |
| 16:11 | <yulia> | in my mind this is like a distributed network where each node knows its neighbors but not the whole graph, is that the right image? |
| 16:12 | <yulia> | (with the kid right now so my attention is split) |
| 16:23 | <Kris Kowal> | (same) |