| 14:38 | <shu> | i've been on PTO, is there someone already volunteered to run the call today? |
| 15:14 | <Jack Works> | Maybe I can |
| 15:47 | <Kris Kowal> | I’ll probably be a little late, but I think a round on progress from champions would be good. Nicolò and Caridy have been busy. |
| 15:48 | <Kris Kowal> | And I have not done my homework: you can all still look forward to updates in the compartments explainer and prose for the module proposals feature unlock graph (tech tree if you will) |
| 15:56 | <littledan> | Yeah I'm available to run the call but also happy to defer to others; I haven't prepared anything for today |
| 15:57 | <shu> | 👍️ |
| 16:02 | <shu> | i'm trying to find a free conference room, may be a few mins late |
| 16:03 | <guybedford> | I seem to have misplaced the meeting link again |
| 16:03 | <guybedford> | can someone share it? |
| 16:03 | <littledan> | Dm'd you it |
| 18:32 | <Kris Kowal> | Some high level take-aways from this morning’s conversation with Guy: |
| 18:33 | <Kris Kowal> | Everyone agrees that virtual import hooks are not serializable. |
| 18:34 | <Kris Kowal> | I’m conceding that new Worker().addModule(virtualModuleInstance) should throw an error because its importHook isn’t serializable, rather than just silently stripping it off. |
| 18:35 | <Kris Kowal> | Dan, Shu, and I are still arguing about how import maps get coordinated between workers, but our motives appear to be similar. Shu and I agree that the serialization of a module instance should not close over the import-map. Dan and I agree that relying on an HTTP header to indicate the import map is not sufficient either. So, something will have to give. |
| 18:36 | <Kris Kowal> | It seems like everyone would be satisfied if in the fullness of time, workers can either inherit the host environment’s import-map or be expressly constructed with an import-map, or both. |
| 18:40 | <Kris Kowal> | Guy very briefly alluded to the possibility and constraints on runtime evolution of an import-map, which I think is sufficiently tricky that I’d like to not think about it. But, in short, import-maps could evolve at runtime as long as appending a new scope does not contradict any resolution already achieved. That problem is considerably simpler if it’s not possible to resolve references that are outside of a known scope. |
| 18:40 | <Kris Kowal> | Otherwise, whether a new scope can be added depends on whether a module in that scope was already loaded. Yikes. |
| 18:42 | <Kris Kowal> | Similar weird things around appending a scope that has a common prefix with an existing scope. |
| 18:45 | <guybedford> | Great summary, thanks Kris for the clarity. With regards to import map extension, there was some fruitful discussion in https://github.com/guybedford/import-maps-extensions/issues/17. For most use cases though, I think web sandboxes just are fine with using iframes. So the 99% use case remains static maps as opposed to dynamic. I can get behind serialization or not, ideally only as an alternative if there aren't other means of achieving the use case. |