TC39 Module Harmony on 2022-06-28

09:49	<Surma>	Is there a loader call today?
09:56	<Surma>	nvm, found the notes doc and it says next call is Jul 6 :)
09:56	<Surma>	Apologies for missing the first call. I must have forgotten to subscribe to the issue
11:11	<Surma>	Kris Kowal: Thanks for making the slides very consumable by themselves. Enjoyed reading them.
11:14	<Surma>	One thing that is currently not quite clear after the slides: Was there tension for module blocks capturing `import.meta.url` of the module they are syntactically embedded in? I believe that’s crucial for module blocks to be successful.
11:29	<nicolo-ribaudo>	With the long messages above we concluded that the tension is solvable, by separating the concept of "module source" (equivalent to the actual contents of an ESM file) and "module instance" (which has the runtime metadata such as import.meta)
11:30	<nicolo-ribaudo>	Module blocks would be the second
11:38	<Surma>	I think that makes sense, ty
14:36	<littledan>	Wait, I think there are three things, the "source", the "instance" (which includes imports) and then this third thing which module blocks and fragments are, where their imports aren't bound but where they do have an import.meta.url
15:05	<Kris Kowal>	I assume module blocks and fragments can be used on hosts that do not provide import.meta.url. Do you mean a referrer internal slot?
15:05	<Kris Kowal>	I think quite a bit hinges on this referrer property, where and whether it exists.
15:07	<Kris Kowal>	There is certainly a formulation of module loaders where module instances do not capturer their referrer but are still suitable for bundlers, import mappers, hot module replacement, &c.
15:08	<Kris Kowal>	Though retaining the referrer wouldn’t break those motivating cases and would probably help more than hurt.
15:37	<Surma>	The use-case that drives this is the following: It’s quite common (on the web) to refer to assets using the “new URL” pattern, i.e. `const imgURL = new URL("./hero-image.png", import.meta.url)`. This ensures that the path “./hero-image.png” is resolved relative to the module. I want to make sure that this continues to work, even if the modules is postMessage()’d to another realm, which means the module block needs to have the same `import.meta.url` as the module it is syntactically embedded in.
15:38	<littledan>	I assume module blocks and fragments can be used on hosts that do not provide import.meta.url. Do you mean a referrer internal slot? Yes, that was just shorthand/an intuitive way of describing it
17:03	<Kris Kowal>	The use-case that drives this is the following: It’s quite common (on the web) to refer to assets using the “new URL” pattern, i.e. `const imgURL = new URL("./hero-image.png", import.meta.url)`. This ensures that the path “./hero-image.png” is resolved relative to the module. I want to make sure that this continues to work, even if the modules is postMessage()’d to another realm, which means the module block needs to have the same `import.meta.url` as the module it is syntactically embedded in. Agreed. In perhaps an excessively pedantic stance, I suggest that is a side-effect of carrying import.meta, which may or may not include url depending on the host. Whereas, a referrer is the key in any module related maps regardless of whether it’s a URL. In XS or in a bundle, there would not be a meaningful URL.
17:04	<Kris Kowal>	But yes, in the not-so-special case of web sending to web, the URL and referrer should be the same and carried with a module block to a web worker.
23:38	<shu>	https://github.com/tc39/incubator-agendas/blob/main/module-harmony-notes/2022-06-21.md