2022-07-01 [13:50:10.0331] Caridy (and by association Daniel) have convinced me that we can use `importMeta` as in `new Module(source, importHook, importMeta)` and in `importHook(importSpecifier, importMeta)` to stand in for a “referrer” and that every host environment would still be able to emulate every other host environment. The key is that `importMeta` is object identical in these cases so can be used to carry a gensym or as a key in a WeakMap, even though it’s not identical to the `import.meta` that the evaluated module sees (unless we change that in ecma262 too!). [13:52:49.0047] Caridy and I have also come to an agreement that the next revision of the compartments proposal will reify the constructor named `Module` since we believe module harmony will likely mean `module {} instanceof Module`, where `Module(source, importHook, importMeta)` generates unlinked, linkable, initializable instances of modules. [13:56:37.0723] I’ve also agreed that there’s no need for the module constructor to _ever_ have an option to override the execution context of the module instances it creates. We can carve out a supplemental proposal for a reified `new ExecutionContext()` that would carry new evaluators `eval`, `Function`, and `Module` bound to the same [[Realm]]. Between `Module`, `ModuleSource`, and `ExecutionContext`, we would have everything we need to build compartments in user code. We could still go on to provide a `Compartment` constructor in the language, but the motivation would purely be ergonomics and would be entirely orthogonal to these primitives, which we agree ought to be exposed. [13:58:01.0090] * I’ve also agreed that there’s no need for the module constructor to _ever_ have an option to override the execution context of the module instances it creates. We can carve out a supplemental proposal for a reified `new ExecutionContext()` that would carry new evaluators `eval`, `Function`, and `Module` bound to the same \[\[Realm\]\]. Between `Module`, `ModuleSource`, and `ExecutionContext`, we would have everything we need to build compartments in user code. We could still go on to provide a `Compartment` constructor in the language, but the motivation would be ergonomics and performance, and would be entirely orthogonal to these primitives, which we agree ought to be exposed. [14:10:33.0757] I’ve also convinced myself that, if module instances locally memoize the results of their `importHook` for both static and dynamic import, and since the import hook returns module instances, we can induce that import is sufficiently idempotent in aggregate to prevent all useful surprises. Compartments allow for those memos to be slightly more economical with memory, but probably not in any meaningful way in practice. Again, no reason we couldn’t have both in the fullness of time, but I’m convinced we should focus on the `Module` and `ModuelSource` primitives. [14:12:03.0687] * I’ve also convinced myself that, if module instances locally memoize the results of their `importHook` for both static and dynamic import, and since the import hook returns module instances, we can induce that import is sufficiently idempotent in aggregate to prevent all useful surprises. Compartments allow for those memos to be slightly more economical with memory, but probably not in any meaningful way in practice. Again, no reason we couldn’t have both in the fullness of time, but I’m convinced we should focus on the `Module` and `ModuleSource` primitives. [14:13:44.0585] I also believe that there is no better contender for the enormously self-assured name `Module`. My expectation is that `Module` will be backed by the Last Module Record type we ever need and that all meaningful extensions to the module system are different kinds of module source, not new kinds of module instance. [14:19:03.0641] Caridy is focusing on a minimal layer that achieves parity with the current behaviors of ecma262, just reifying these two functions. I propose, in addition, that the `Module` constructor receives a ***Module Source Protocol*** implementation object, like `{bindings?, initialize?, needsDynamicImport?, needsImportMeta?}` which instances of `ModuleSource` happen to provide. This would be sufficient to define JSON, CommonJS, WASM, &c module sources in user code. However, that protocol would not be adequate to carry CSP information for vetted module sources and would not preclude the introduction of other host-defined module source classes. I expect only host-defined module source classes would be transmissible via structured clone and cary host-vetted origin metadata. [14:21:24.0122] I’ve also been convinced that the first argument to `initialize` should be called a ***Module Imports Namespace Exotic Object*** (not a reification of the entire definition of ***Module Environment Record***, just an exotic object that can be used to get and set the import and export bindings of the module, in its internal namespace. 2022-07-02 [19:45:36.0664] yulia: Goal: The ability to evaluate modules in isolated execution contexts and shared frozen intrinsics, or rather, a foundation on which that can be built. [19:48:54.0163] That’s at least the pretext on which I can conscionably work on this as an Agoric delegate! As a JavaScript user, though, eval-but-for-modules has been a personal goal for a long while now. I proposed a `Module` constructor to TC39 in January of 2010! [00:27:28.0346] Kris Kowal I really like this new direction 👀 2022-07-03 [09:29:53.0611] > <@kriskowal:matrix.org> In any case, I sketched this, borrowing as much as possible from the Compartments proposal https://gist.github.com/kriskowal/288d38e62e55e09685bf62c3a3c25565 > The compartment will leave that promise to dangle, so an eventual rejection will necessarily go unhandled. I don't agree with this part. If the module throws sync, it will become a sync error that can be caught, but if the promise dangles, I cannot handle it. This creates inconsistency in if module uses TLA or not [09:35:26.0826] I also don’t like it, but couldn’t think of an alternative behavior. Answering that point consistently with the current host behavior would be ideal. [09:36:05.0725] But also, if we reduce the scope to `Module` and `ModuleSource` constructors, I don’t believe we have to answer the question in our proposal. [09:36:13.0433] Can't it spread to where the import happens? [09:36:52.0936] Is that the behavior of dynamic import for a module and its transitive dependencies when any of them contains top-level-await? [09:37:05.0742] Genuinely, not an expert on TLA. [09:38:03.0609] That is, does the promise returned by dynamic import settle only when all of the transitive dependencies settle for TLA? [09:38:48.0534] And I wonder how much code I need to write in the user land for the housekeeping work (e.g. module caching stuff), so I can emulate a normal ES module environment (with some built-in modules and a relative path module resolution)? I would like to see an example. [09:39:35.0561] > <@kriskowal:matrix.org> Is that the behavior of dynamic import for a module and its transitive dependencies when any of them contains top-level-await? I believe so, otherwise what should be the result of that dynamic import? [09:40:15.0764] The promise returned by dynamic import could settle after all first turns are completed. [09:40:31.0928] Not that I think that’s sensible, but I don’t assume. [09:40:43.0435] And I haven’t yet read :-) [09:41:43.0331] In any case, I think it will be sufficient to fix that text to match whatever already exists, or delete it if we don’t have to specify the behavior in the module loader / compartments proposal. [09:42:15.0129] As for how much needs to be done in user code, I need to write a sketch of implementing Compartment in user code, in terms of Module, ModuleSource, and ExecutionContext constructors. [09:42:25.0313] I’m expecting to write a couple hundred lines. [09:46:22.0302] Again, I know almost nothing about top-level-await, having not used it nor watched the proposal develop. Very much dependent on an expert to call out the right answer for sinking promises. 2022-07-04 [01:09:09.0166] I am -sick as heck- y'all [01:09:20.0802] I will not be able to run the meeting on wednesday, or attend at all [01:09:31.0140] shu: do we have an alternative facilitator? 2022-07-05 [02:27:08.0275] Can someone add surma@shopify.com to the calendar invite for the recurring Loader meeting? [02:27:14.0599] yulia | Out of Office until July 11th: Hope you feel better soon! [09:51:11.0876] Surma: Note that you may be able to add the whole TC39 calendar for yourself from https://calendar.google.com/calendar/u/0/embed?src=mozilla.com_l7b50itpaa9bnrvr61nebqrne8@group.calendar.google.com&ctz=America/Los_Angeles [10:19:53.0276] > <@littledan:matrix.org> Surma: Note that you may be able to add the whole TC39 calendar for yourself from https://calendar.google.com/calendar/u/0/embed?src=mozilla.com_l7b50itpaa9bnrvr61nebqrne8@group.calendar.google.com&ctz=America/Los_Angeles Yeah i did do that! Thank you! I'm just keen to get a reminder for this specific one ;) [10:49:30.0117] > <@yulia:mozilla.org> shu: do we have an alternative facilitator? I believe I should shadow a facilitator before I volunteer for that role, but if nobody steps up, I will definitely do my best impression. My understanding is that this mostly involves making sure agenda and minutes get captured, in addition to shepherding the meeting. [10:53:22.0418] I’ve sketched an agenda: 1. Overflow from my kick-off on Module Harmony thru the Compartments lens 2. nicolo-ribaudo on Module Harmony thru the lens of Module Blocks’s emerging spec text 3. caridy on minimum-viable first-class Module and ModuleSource [10:57:36.0591] I believe yulia | Out of Office until July 11th had in mind some important front-matter to get us all on the same page for each other’s hopes and expectations from module harmony, which I think we ought to pursue as early as possible. I can also attempt to facilitate that, though I’m also not confident I can fill Yulia’s shoes. [10:58:01.0167] That is, in fact, probably more important to articulate than any of the above. [10:59:09.0463] To that end, please give me a thumbs up here if you’re prepared to speak to your own hopes and expectations of Module Harmony tomorrow. [10:59:25.0990] Perhaps we can do a round-the-room. [11:02:57.0355] (And of course, I hope any other convener can lead this conversation since I don’t expect anyone to trust my impartiality!) [11:56:22.0627] I can help with convening if Yulia is out but at the same time maybe we should just wait until she gets back? [13:27:00.0177] > <@littledan:matrix.org> I can help with convening if Yulia is out but at the same time maybe we should just wait until she gets back? This would probably be wise, as the premise of this harmony group is to keep all stakeholders on the same page. [13:28:38.0262] I'd like to propose, for an upcoming meeting, a discussion of how we've figured out how a lot of the space factors into three mostly orthogonal proposals (module reflection, module blocks/fragments, and the loader) since I think we made a lot of progress on that in the past couple weeks [13:29:53.0281] Agreed. I’d also like to focus on how the points of intersection appear to be coherent. [13:30:11.0313] top agenda item: How do we name ModuleInstance/ModuleBlock :) [13:30:49.0793] I think with some effort over the next week, we could arrive at the harmonious conclusion: `Module`. [13:31:44.0081] And the desugarring of `module {}` to `new Module()`. [13:32:24.0406] hmm, maybe. I feel suspicious but I'm fine with that as a working title [13:32:28.0927] It seems likely to me that, even if the notion of a `Compartment` survives, the notion of a module descriptor probably merges into `Module` instances. [13:32:38.0358] (basically for the reasons you gave in your last presentation) [13:32:45.0697] Yes, rightly suspicious. [13:33:39.0187] Some of my thinking, chronicled above, has changed over the last couple weeks. [13:35:00.0192] Since Caridy’s been challenging my assumption that 262 would need to subsume module maps. Nicolò has also been moving in the direction of subsuming module maps. Not sure whether we’ve crossed positions, but that would be funny. [13:35:28.0963] huh, what do you mean by subsuming module maps? [13:39:39.0171] And Nicolò also learned this morning that HTML anchors module maps in an unexpected place: on module instances. That’s surprisingly consistent with what Caridy is proposing. [13:41:30.0314] I mean that module maps are currently implied into existence by 262, through host behaviors. There isn’t a [[ModuleMap]], say, on a Realm record. (Qualifier: this is hearsay. I’m not sufficiently intimate with 262 to purport the non-existence of anything within its pages.) [13:43:58.0724] Caridy’s driving toward a simplification of the compartment proposal that notably omits Compartment. I’m convinced that it’s functionally equivalent, even up to preserving all useful idempotence invariants and compatibility with our hardened JavaScript objectives. Omitting compartments effectively moves all module memoization behavior to a new kind of concrete Module Record, say, Virtual Module Record, which would be reïfied by a `new Module` constructor. [13:45:11.0180] (note: the specific word in html for module instances is "module scripts") [13:45:16.0041] And I understand that you, Daniel Ehrenberg , provided the useful insight that the `importMeta` is sufficient to imply a referrer without having a dedicated referrer argument on a `Module` constructor. [13:47:45.0526] I have to think about this more, but after I talked with you (Kris) I'm convinced that my direction and how I understood Caridy's direction from you are not inconciliabile [13:48:14.0732] Always assuming that compartments are exactly as much powerful as hosts [13:48:40.0726] * Always assuming that compartments/"reified modules" are exactly as much powerful as hosts [13:48:47.0516] My opinion is that, to use the name `Module`, it must be exceedingly worthy. That is to say, there must never come a time in the evolution of 262 that we reify an object that is worthier of the title or create a class where this particular kind of module is no more special that the others. I believe it meets that criterion iff it turns out that all specialization of modules going forward is sufficiently addressed with new types of Static Module Record. [13:49:24.0368] > <@nicolo-ribaudo:matrix.org> I have to think about this more, but after I talked with you (Kris) I'm convinced that my direction and how I understood Caridy's direction from you are not inconciliabile Is this to say, you believe these directions are compatible? [13:50:26.0173] I’m hopeful that they are. [13:50:27.0693] Yes. The things I added in the modules block spec are all "spec internals", and they shouldn't affect the exposed API in any way [13:51:09.0487] > <@kriskowal:matrix.org> And I understand that you, Daniel Ehrenberg , provided the useful insight that the `importMeta` is sufficient to imply a referrer without having a dedicated referrer argument on a `Module` constructor. Caridy seems to have run with this further than I thought possible [13:51:36.0108] We may have run together. [13:51:45.0350] So I’ll unpack what we learned. [13:52:22.0681] > <@nicolo-ribaudo:matrix.org> (note: the specific word in html for module instances is "module scripts") Can I also say that I don't like this name either? :) [13:52:46.0362] Yes, it's the most confusing name possible [13:52:59.0510] Assuming `new Module(source, importHook, importMeta)` is sufficient, `importMeta` is _not_ identical to `import.meta` as seen by the source, but _is_ identical to the object received by `importHook` to address the referrer, as in `importHook(importSpecifier, importMeta) => Promise`. [13:53:54.0579] That is to say, that in user code, one can arrange a side table from `importMeta` to `referrer` and it’s sufficient that import hooks know about it. [13:54:20.0126] I was thinking about it and... I'm not sure if importHook is at the same level as importMeta. At least, when serializing and deserializing a Module, you'll often preserve the importMeta and swap in a new importHook [13:54:31.0417] (along with giving it a new identity) [13:54:34.0452] That allows for the possibility, as is necessarily the case for some environments, that neither `import.meta.url` and `import.meta.resolve` are available for an `importHook` to use, much less necessarily trust. [13:54:55.0388] "preserve" importMeta in an abstract sense, though--it will surely be a different object identity [13:55:16.0374] > <@kriskowal:matrix.org> That allows for the possibility, as is necessarily the case for some environments, that neither `import.meta.url` and `import.meta.resolve` are available for an `importHook` to use, much less necessarily trust. hmm, why? [13:55:19.0284] Yes, `importMeta !=== import.meta`. [13:55:29.0659] oh! really? [13:56:07.0098] I should say, not necessarily ===. [13:56:41.0635] now I'm even more confused [13:57:15.0681] What i’m saying is that, for the purposes of this side table, importMeta as given to the constructor may be copied over an Object with a null prototype and all useful properties of import hooks are preserved. [13:58:20.0869] I’m not saying that they can’t be identical. It probably wouldn’t be useful to create a new mechanism that allows `import.meta` to be a number or a proxy. [13:58:43.0908] One way to do that would be copying properties. Another would just be to assert its nature. Asserting it’s not a proxy is somewhat hard. [14:01:36.0314] > <@littledan:matrix.org> hmm, why? Continuity with the past. The alternative is to suggest that this virtualization be limited to situations where `import.meta.url`, `import.meta.resolve`, or some other property carries the referrer in another host-defined sort of way. Not all existing environments meet that bar. I’m not suggesting this is a blocker. I’m suggesting that it’s definitely not a blocker. Those environments can be emulated with a side table keyed on `importMeta`, regardless of whether that’s identical to `import.meta`. [14:03:00.0044] Which is to say, the problem I imagined with not enshrining `referrer` in the `Module` constructor, turns out to be imaginary. [14:03:57.0442] Now, whether the same reasoning applies to module blocks remains mysterious to me. [14:04:57.0207] That is, whether it is sufficient to serialize `import.meta` when reconstructing an equivalent module in another worker, as opposed to serializing a [[Referrer]] internal slot. [14:05:20.0154] (To the extent that import.meta is serializable!) [14:05:32.0049] But isn't `import.meta` lazily-initialized (on first access), so potentially not available when transferring a module block? [14:05:49.0158] As written today, yes. [14:06:17.0434] Lazy initialization of `import.meta` could be copying properties from `importMeta`. [14:06:38.0746] Regardless, if we relaxed the verbiage around lazy initialization of `import.meta`, the change wouldn’t be observable. [14:13:34.0385] Bradley related to us at a SES call of yore that Node.js depends on this laziness to avoid instantiating an `import.meta.resolve` closure for every module. That gets created lazily on the first evaluation of `import.meta`. In the Compartments proposal, we solved that problem by adding a `needsImportMeta` property to `ModuleSource / StaticModuleRecord` instances such that a `loadHook / importHook` can avoid building an `importMeta` except for modules that are likely to need it, by reflecting static analysis. [14:14:00.0523] Caridy’s direction preserves that solution. [14:14:07.0004] > <@kriskowal:matrix.org> Regardless, if we relaxed the verbiage around lazy initialization of `import.meta`, the change wouldn’t be observable. yeah it only seems observable given a sufficiently visible host [14:14:12.0168] which, probably doesn't exist right now [14:14:25.0545] It might with the experimental Node.js Loader. [14:14:42.0819] I’m inclined to hope that we get ahead of that here. [14:15:37.0886] And if a host virtualization hook is running synchronously during the first evaluation of `import.meta`, that seems needlessly foot-gunny. [14:19:31.0752] shu, littledan We probably ought to decide and communicate a cancellation for tomorrow’s meeting. Are either of you positioned to reach all participants? [14:20:50.0157] FYI I posted https://github.com/whatwg/html/issues/8077 for making `import.meta.resolve` a generic resolver [14:20:58.0108] which might be a useful technique for loaders to get access to the global resolver [14:21:39.0369] Kris Kowal: are you referring to the SES or modules meeting tomorrow? Is this because we don't have someone to run it? [14:22:46.0533] Yulia being absent leaves us without a convener, but more importantly, leaves us without an important stake holder. [14:23:08.0782] * Yulia being absent leaves us without a convener, but more importantly, leaves us without an important stakeholder. [14:23:19.0958] It may still be useful to have the discussion if we can [14:23:41.0109] Didn't shu give host credentials to others as well? [14:23:57.0164] Has no one else come forward to assist with convening? [14:23:59.0999] Yes, others can open the meeting. [14:24:10.0675] Dan has come forward to assist with convening if we convene. [14:24:40.0664] Even if we don't have all stakeholders, we should still have notes to share and can continue to build some shared understanding on the matters [14:25:01.0961] > <@guybedford:matrix.org> Didn't shu give host credentials to others as well? Yes, I should have credentials in theory [14:25:25.0512] I think there’s a hope that we move forward together. Discussions are obviously great, but we don’t want to assume that the shared context has advanced. [14:26:26.0815] That is, if we have any module harmony conversations outside of these “incubator” calls, we need to expect to present our findings again on the call. [14:27:12.0793] I think we are still very much in a phase of discovery here [14:27:20.0939] This is true. [14:27:30.0151] so that it's less about decisions and more about continuing the conversations [14:27:44.0755] there's still a lot to discuss! [14:27:49.0175] I read you’re in favor of having a conversation. [14:27:59.0253] I’m also very aware that we have two weeks to plenary. [14:28:15.0846] And that I have put my foot into the agenda. [14:29:02.0790] Myself and Luca at least would value giving a 10 minute update on where we would like to take import reflection, and before plenary, to ensure we don't step on any toes [14:29:49.0113] we want to ensure we're getting the cross-concerns right [14:30:21.0675] One option is that I can reconvene the SES meeting. [14:30:47.0953] the hope for these meetings, at least for myself, was to be able to see how the pieces of the puzzle can fit together to form a wholistic picture [14:30:57.0521] Same, agreed. [14:31:14.0688] > <@kriskowal:matrix.org> One option is that I can reconvene the SES meeting. Aren't "SES meeting and let's talk about modules" and "Modules meeting" effectively the same thing? [14:32:10.0259] No, we have an agreement that any findings from the SES meeting will be reprised at the Module Harmony group so that the broader group of stakeholders can stay in sync. [14:32:41.0301] Ok right, it would be good then. I don't think we should come to a "group decision" without all the important stakeholders [14:32:42.0190] We can of course retcon our findings so we’re not presenting the incoherent ideas! [14:33:19.0561] Not sure what you mean by "reprised" but yeah as Nicolo says the important thing is that we don't think of anything from SES as having reached a group decision, but instead having had some interesting discovery-oriented discussions [14:34:02.0457] It’s also important that group decisions don’t come out of the modules harmony calls, but I think we’re mostly on the same page 😉 [14:36:12.0614] In any case, I’m going to continue making slides and will expect to share them in one venue or another. [14:36:41.0264] And it would be good for us to communicate a decision. [14:40:08.0934] It would be good to work through the slides further, it would also be good to have a few mins for us each to share our respective updates [14:40:59.0020] we could probably present the current import reflection thinking in about 5 - 10 mins [14:41:18.0964] we are actively seeking feedback [14:42:04.0035] would it be possible to complete the slides in 30-40 mins? [14:42:19.0273] would definitely be useful to continue building out the shared context [14:42:39.0573] or is the problem Kris Kowal that you would prefer to have Yulia present for that? [14:43:55.0557] I intend to present an abbreviated deck from the overflow from the prior meeting. [14:44:31.0470] I think Yulia would have kicked this meeting off with an around-the-room of each of our goals. [14:45:03.0559] I’ve asked Nicolò to show what he’s learned over the last two weeks from writing up spec text for module blocks. [14:45:40.0429] I’d be elated to give you guybedford the floor to sync up on import reflection. [14:46:20.0478] Caridy will miss the first 20', but I’m hoping he gets a chance to share his vision for `Module` and `ModuleSource`. [14:47:47.0291] And I think it’s not too premature to share his sketch (cc nicolo-ribaudo) https://gist.github.com/caridy/98f61cf6100243c3cecef5c16a4eff2d [15:12:39.0329] Yeah well I'm up to convene/facilitate a discovery-oriented discussion as long as we plan to come back and reconsider things when stakeholders are available [15:13:06.0684] so we can do this tomorrow at the time in the calendar if people want to [15:24:42.0969] That at least has the virtue of not requiring last minute comms. [15:24:54.0334] And also an extra half hour of talk time. [15:38:20.0134] I will have to drop off at the top of the hour unfortunately, so it’d be great if we can cover import reflection some time in the first half of the meeting [15:41:33.0124] I’m going to defer my overflow deck to a subsequent meeting. I’m writing Luca Casonato and guybedford into the agenda as the opening act. [15:42:02.0314] Also moved Goals to the next meeting for Yulia. [15:43:12.0521] The agenda is a writable link off the TC39 calendar invitation. [15:45:07.0670] Thanks Kris 2022-07-06 [18:07:06.0251] I’ve finished a deck for tomorrow, should time permit. I added this to the end of the meeting as it shows where I think we’re converging. https://drive.google.com/file/d/1_juf8l8PCrVHA4iA1G4BwQ1JsuXMjOVa/view [23:53:28.0016] > <@kriskowal:matrix.org> I’ve finished a deck for tomorrow, should time permit. I added this to the end of the meeting as it shows where I think we’re converging. https://drive.google.com/file/d/1_juf8l8PCrVHA4iA1G4BwQ1JsuXMjOVa/view I like this. Where does the module descriptor go? [00:11:22.0336] Module descriptors cease to be necessary. When implementing a Compartment in user code, module instances replace module descriptors. User-mode Compartments aren’t able to address modules from the host compartment by name, but import reflection replaces that role. [00:13:56.0058] e.g., `defer import fs from 'fs'; new Compartment{{ modules: { fs } }).import('fs')` is a possible solution with a user-code Compartment implementation. [00:14:57.0283] (where `defer import` is import reflection. I haven’t seen a syntax I like for that yet, so just riffing here.) [00:23:06.0820] Actually, for inter-compartment linkage, we would have to implement module-descriptors in user code. [12:29:40.0452] Are any champions going to seek advancement for module proposals at the next plenary? [12:30:40.0510] We are planning to seek stage 2 [12:32:21.0263] I propose that I repurpose the slot I’ve reserved for compartments to deliver a module harmony, based on where we are as of this morning. My impression is that we need more work on module harmony before we have a proposal that can advance to Stage 2. [12:33:30.0932] In my opinion, none of our proposals should advance until we have a shared foundation, and as far as I’m concerned, that shared foundation could be bundled into any proposal seeking stage 2 or greater. [12:34:27.0119] By the shared foundation, I mean the modifications to the abstract module record hierarchy on which we all likely depend. [12:35:22.0467] * I propose that I repurpose the slot I’ve reserved for compartments to deliver a module harmony report, based on where we are as of this morning. My impression is that we need more work on module harmony before we have a proposal that can advance to Stage 2. [12:36:24.0472] * By the shared foundation, I mean the additions to the abstract module record hierarchy on which we all likely depend. [12:37:32.0950] Kris Kowal: I'm not sure we should let specification editorial details block individual proposals. As long as each proposal is semantically sound, and we are tackling the shared interaction problems, I don't think we need to converge on sharing exact spec text between proposals especially at this stage. [12:38:25.0970] For import reflection, I think the syntax pivot is good. I can see `import module` and `import static module`. I would be okay with `import static module` reifying the literal WASM `Module` object provided that it can be passed to a `new Module(wasmSource, importHook, importMeta)` when first-class modules come. [12:40:00.0590] My understanding is that stage 2 requires tentative spec text. I’m asking that any proposal that advances have tentative spec text that is sufficient for any other module proposal to build upon. [12:40:25.0575] I could be wrong. This is my first stage advancement rodeo. [12:41:11.0948] But I believe the guiding principle is right: we should not paint ourselves into a corner that would preclude advancement of other proposals, or produce avoidablee scar tissue. [12:41:18.0814] * But I believe the guiding principle is right: we should not paint ourselves into a corner that would preclude advancement of other proposals, or produce avoidable scar tissue. [12:41:42.0719] But I’ll qualify that: spec text scar tissue does not bother me. Reified object scar tissue does. [12:42:10.0007] Right, although Stage 2 is not an implementation stage [12:42:24.0275] Only at Stage 3 does scarring start to occur! [12:43:10.0411] In our current specification we defined the mechanics of the reflection, but we have left the actual reflection object being returned to be entirely defined by the host for now [12:43:22.0001] through a HostResolveModuleReflection hook [12:43:36.0348] our hope is that this is clear enough for stage 2, without being too prescriptive yet [12:43:54.0298] we would hope to refine for stage 3 some further invariants around the resolution and exact JS reflection object [12:44:02.0690] but for now we just treat it as host defined [12:44:35.0315] I would be interested to hear if that mitigates your concerns, the spec text PR is up at https://github.com/tc39/proposal-import-reflection/pull/21 and should be landing soon [12:44:47.0021] I’ll give it a read. [12:45:26.0526] The invariant I would hope to preserve would be `new Module(x, …rest)` would work for any `x` reflected by `import static module ...`. [12:45:53.0729] And I would cut it as fine as differentiating `import module` from `import module static`. [12:47:09.0639] I think it is important that `import module x from 'x.any'` should always produce `x instanceof Module` whereas there’re more degrees of freedom for `import static module x from 'x.any'`. [12:47:26.0843] as mentioned in the meeting, we are only interested in the `import module` being the `import static module` case you describe [12:47:41.0074] I’m interested in both existing. [12:47:41.0815] we don't have a use case for the module instance reflection [12:47:57.0458] Deferred execution is the motivating case for module instance reflection. [12:48:05.0160] specifically - what would the import hook be for an implicit instance reflection? [12:48:39.0833] deferred execution is not a use case of reflection either, and we have mentioned before this is separate specification work [12:48:51.0661] import instance reflection would inherit the surrounding module instance’s import hook. [12:49:37.0897] In my current mental model, these occupy overlapping syntactic space that should be coherent when we have solutions to both problems. [12:49:47.0079] it sounds very much like a deferred import [12:49:51.0555] It is. [12:49:58.0888] That is Yulias area not ours [12:50:24.0947] I think it can be achieved but it is a separate specification to what we are working on with module reflection [12:50:32.0196] "reflection" by its nature is about a higher order import [12:50:34.0997] not an instance import [12:50:52.0573] I do not mean to suggest that your proposal should solve both motivating use cases. [12:51:07.0454] I do suggest that we are responsible for ensuring that these merge without conflict. [12:51:36.0073] it is our collective responsibility to not conflict eachother yes :) [12:51:37.0690] I suggest that in the end we should have syntax for both cases. [12:52:03.0680] that's fine, and nothing is precluded [12:52:25.0221] specifically we have further constrained import reflection to module import reflection [12:52:51.0516] other proposals for other types of imports like assets or deferred execution can easily coexist [12:52:54.0094] `import module x from 'x.js'` meaning x instanceof `WASM.Module` would preclude `import module x from 'x.js'` alternately meaning `x instanceof Module`. [12:53:07.0575] right but it doesn't preclude `import defer x from 'x.js'` [12:53:22.0366] I agree that is possible. [12:53:51.0490] In a universe with both, are we creating another footnote in WAT.js? [12:54:11.0585] if there is issue with the `module` term not being clear enough, we can consider other options [12:54:19.0362] the hope was too avoid too much of a bikeshed of course [12:54:19.0804] ``` import module x from 'x.wasm'; x instanceof Module; // false WAT? ``` [12:54:31.0687] I hope we could consider this mostly aesthetic as opposed to a primary stage 2 concern [12:55:14.0000] I’ll grant this is aesthetic. What stage do aesthetics become a concern? [12:55:48.0931] Soft concern for 2, hard concern for 3? [12:58:46.0093] From what I believe, stage 2 is expected to be complete specification but can still have open questions [12:58:58.0353] I’ll also grant that `import defer x from 'x.any'` has a nice ring to it. [12:59:39.0632] we'll make sure to highlight these points, this has been useful [13:35:46.0505] I think we still have a number of foundational questions to answer, for all of the proposals we're discussing. A number of unresolved points of disagreement just came up in that meeting. I'm fine with things moving to Stage 2 as long as this is to be interpreted explicitly as "we agree that we want to move forward as a committee in this area, and have one concrete idea of how it might work, but we're still open to resolving these foundational questions in multiple ways" [13:36:18.0817] > <@guybedford:matrix.org> From what I believe, stage 2 is expected to be complete specification but can still have open questions Stage 3 is complete specification, for stage 2 you need a draft [13:36:41.0320] I mean, module blocks seems to be one of these proposals which has these unresolved foundational questions, and it's already at Stage 2! But this is largely because it hadn't yet occurred to us that module blocks might be referrer-less, which Caridy is now advocating [13:37:35.0721] I don't tend to agree with people who insist that all foundational questions be addressed by Stage 2. It's just too common for us to find that we need to revisit foundational issues during Stage 2. I think it's more that, Stage 2 indicates a level of interest/resolve to work things out, together with concreteness on *some* possibility [13:37:51.0214] the bikeshed is definitely not a Stage 2 blocker [13:39:02.0468] I think we should at least wait until Yulia is back to conclude that deferred module evaluation is separate from Guy's and Luca's proposal. I've heard multiple suggestions that these are really the same space. So if Stage 2 were to be taken to mean, "these are definitely separate"... I wouldn't be ready to say that yet. [13:41:05.0854] Concretely, I hope we can all get more space to decide whether module blocks and reflective modules are ModuleSource or Module values. My expectation was that they were both Module, but Guy was proposing that reflective modules be ModuleSource, and Caridy was proposing that module blocks be ModuleSource [13:41:17.0273] I think we can iterate here after Stage 2 but before Stage 3 [13:41:27.0307] * I think we can iterate on this question after Stage 2 but before Stage 3 [13:43:17.0831] I was disappointed that asset references fell out of what Guy and Luca are proposing initially. I'd be interested in hearing more about what's behind that decision, and how soon you'd like to follow up with asset references, since they seem quite useful. [13:52:14.0399] guybedford: Luca Casonato I'd be happy to have a call with you some time soon to discuss all this more if you're interested [14:55:26.0362] Same [14:56:06.0763] And I’m putting together a review to call out at least where I think we’re headed tentatively where it doesn’t match. Emphasis on tentative. [14:56:52.0905] If I read the room right, I should hurry up and put together some spec text for first class modules (Module and ModuleSource) and shoot for the two. [15:02:23.0610] And I think Caridy and I both suggest `module {} instanceof Module` and `static module {} instanceof ModuleSource`. Serializing ModuleSource is uncontroversial. Serializing Module is controversial. By the end of the call, I think we had agreement that Module, if serializable, is intentionally cherry picking the serializable subset of the instance. However, Caridy, Guy, Shu, and I all have misgivings. I have made peace with my misgivings. [15:05:08.0714] My feeling is that trusting the sender and receiver to have identical importHook behavior is possible but fragile. But, if we have blocks, static blocks, `Module` and `ModuleSource` to work with, I think that the ecosystem will have everything it needs to come up with more sensible protocols for sending modules to workers. [15:07:19.0410] That is to say, I predict that `worker.import(module {})` will look good in examples but will otherwise have limited utility. But, that’s okay with me. [15:39:02.0649] @littledan thanks for the feedback, we see module reflection as laying down an approach that asset reflection and deferred execution can follow in, as opposed to the original more abstract view of a generical mechanic. Trying to be practical and use case focused while treating generalization as a possibility but not to over-generalize. We are keen to see asset references and deferred module loading move forward, we are just trying to focus our efforts in a way that keeps scope clear in the staging process. We currently are underspecifying what exactly the shape of the reflection object is though, and treating this as a detail to be refined as opposed to prescribing it at this point. The way we do this for now is to entirely delegate it to a host hook, then the hope for Stage 3 would be to follow-up with an exact definition for JS that will hopefully have progressed by then. We need the host hook regardless for Wasm though. [15:39:29.0094] all good points, will do our best to address the various nuances! [15:39:52.0568] Definitely agreed feedback from Yulia is needed to progress in many of these discussions at this point [15:43:55.0520] guybedford Am I correct that `new Module(wasmModule, importHook, importMeta)` where `wasmModule instanceof WebAssembly.Module` is a sensible way import reflection for WASM and first-class modules would compose? [15:44:16.0523] That implies that the WASM module can both import and export. [15:44:42.0370] Or is it only sensible to link WASM modules manually? [15:44:44.0384] Kris Kowal: that is definitely an option, and something to be discussed further [15:45:09.0999] We don't currently have a strong opinion on this [15:45:16.0105] definitely keen for more feedback [15:45:35.0338] I would say that is less an option and more a requirement, in my opinion. [15:46:01.0337] Unless web assembly modules are indeed merely resources. [15:47:12.0831] And I think that decision pivots on whether there’s one or more sensible ways to interpret WASM as a participant in a module graph. [15:48:56.0629] If there’s more than one way, I would lean more in the “web assembly modules are assets / resources that we want vetted for CSP, but require further programming to participate in a JS module graph” direction. [15:49:51.0672] But if there’s one way that always works, I’d lean more toward putting them on equal footing with *static* module blocks and `ModuleSource` instances. [15:53:05.0573] From a loader perspective - if we used synthetic module wrappers that would involve using dynamic import to reentrantly load the dependencies. By making Wasm first-class module records they could participate in the module graph equally in the same execution algorithm as opposed to being treated as having reentrant dependencies which would otherwise deadlock for cycles [15:53:44.0050] Wasm doesn't strictly need cycles, but the point stands that it would involve user instrumentation for loader support using reentrant dynamic imports that could deadlock [15:54:15.0961] a lot of the questions are about expectations and how much work they will be to support in loaders certainly [15:54:26.0104] That’s a lot to unpack. [15:54:59.0450] I don’t think literal deadlock is on the table in any framing. [15:55:39.0944] I also don’t think reentrance is on the table. [15:57:03.0419] importHooks are recursive but non-reentrant. They would only run under dynamic import during the load phase, for growing the working set of module records. [15:58:16.0596] I think WASM modules being inherently acyclic is handy, but I also think it’s possible to fully virtualize even ESM, including cycles. [16:01:39.0273] There are a bunch of complexities making them first class to delve into, perhaps we can go through the exercise some time [16:01:39.0824] I think we agree actually that WASM modules _ideally_ participate in module graphs on equal footing with module sources. But, if there’s no sensible default behavior, virtualized module sources are certainly option. Caridy would point out though that virtual module sources don’t serialize and probably would also lose their CSP metadata. [16:02:14.0310] definitely could workshop some example workflows around loader instrumentation and Wasm [16:02:18.0796] So ideally we find a good default behavior. [16:02:20.0143] and work through tradeoffs [16:02:32.0466] ideally having Dan and Caridy present for that would help [16:02:49.0024] That would be a good exercise. [16:04:59.0719] I don't get the feeling it is too pressing right now [16:05:09.0646] or needed before this coming meeting [16:05:31.0439] but if it's something on your critical path there happy to arrange anytime [16:08:33.0187] I think that’s necessary to answer the question of whether `WebAseembly.Module` should be reified as a module source or a resource. I’m pretty sure we need to know the answer before stage 2 since that constitutes a big difference in what you’d be proposing. [16:09:15.0100] * I think that’s necessary to answer the question of whether `WebAssembly.Module` should be reified as a module source or a resource. I’m pretty sure we need to know the answer before stage 2 since that constitutes a big difference in what you’d be proposing. [16:11:05.0010] That is, if import reflection is `import module x from 'x.wasm'`, that’s only coherent if `x` is a module source and requires no further programming to participate in a module graph. [16:19:19.0948] Follow-up question: Is this example coherent in your mental model: ``` import module x from 'x.wasm'; await import(x); ``` [16:20:06.0477] Oh, I know the answer already. That depends on the same exercise. [16:22:52.0741] yes exactly that is the question I think [16:22:57.0208] (I don’t think the example is coherent, but if your answer is yes, that _would_ put WASM modules on equal footing with module blocks and imply that a WebAssembly.Module is linkable without further programming.) [16:23:04.0894] coherency is exactly the question there [16:23:10.0071] if we want Wasm and JS to work the same [16:23:14.0078] or if there will be this difference [16:24:44.0550] I’m sure that your motivating use case is adequately addressed just by carrying CSP into WebAssembly.Module and never incorporating it in a JS module graph. [16:26:09.0061] I guess it would be gross but not broken if `import module x from 'x.wasm'` was completely different than `import module y from 'y.js'`. [16:27:31.0277] But if that’s the case and a WASM module can’t participate in a JS graph, you wouldn’t need anything from 262. WASM could just as well be a module that exports a CSP vetted default WebAssembly.Module. [16:44:58.0503] the problem is how you obtain the `WebAssembly.Module`, also this is a feature Wasm modules themselves in the ESM integration want to be able to get ahold of [16:45:09.0674] Wasm wants to be able to import its own records [16:45:25.0845] that's an important aspect of the component model [16:46:15.0210] there are also further static benefits and static security benefits over arbitrary URL fetching [16:46:33.0378] I’m reading https://github.com/WebAssembly/esm-integration/tree/main/proposals/esm-integration [16:47:05.0478] See also https://github.com/WebAssembly/component-model/blob/main/design/mvp/Explainer.md#ESM-integration [16:48:00.0866] Oh, wow. This depends on `as` notation. [16:48:33.0999] Oh, I’m going to assume this just isn’t synced with your most recent work. [16:49:53.0818] yes exactly [16:50:31.0405] Am I right that `esm-integration` answers the question that WASM does have a sensible way to integrate in a JS graph? [16:51:19.0338] I’m reviewing your draft rn, and I noticed that your primary motivating case is the cases where the default integration isn’t sufficient. [16:51:24.0734] yes although the esm integration is currently awaiting our progress on reflection to move forward [16:51:39.0009] Is it dependent? [16:52:05.0868] in some sense the solution space is dependent in that this is what is needed ergonomically right now [16:56:52.0306] Well, I understand your conundrum better now. [16:58:27.0491] Let’s assume `import module x from 'x.any'` produces `x` such that `x instanceof ModuleSource` and `import defer x from 'x.any'` produces `x` such that `x instanceof Module`. [16:58:41.0822] there is an inferior solution the wasm folks can choose without our involvement at all, by making the default kind of thing returned by `import 'x.wasm'` a `WebAssembly.Module` instead of an instance [16:58:47.0025] it breaks symmetry down the road, however [16:59:36.0333] Right, I was about to propose that strawman until I started reading esm-integration, which suggests there is a reasonable default interpretation of a WASM module as it participates in a JS graph, importing and exporting. 2022-07-07 [17:00:13.0649] i'm not sure it's reasonable, more that it's the path of least resistance [17:00:15.0471] And taking esm-integration at face value, and stated assumption, there’s already a reasonable interpretation. [17:01:37.0916] So, the question is whether it can be simultaneously true that `x instanceof ModuleSource` and `x instanceof WebAssembly.Module`, such that the former could be fed back into the JS module graph, and the latter could be used for manual instantiation. [17:02:19.0603] i don't think that can be done for the existing `WebAssembly.Module` [17:02:34.0327] That seems like a problem. [17:03:21.0839] there are solutions the acceptability of which i'm unsure [17:03:27.0906] WebAssembly.Module.fromModuleSource [17:03:36.0657] WebAssembly.Module2 [17:04:12.0709] WebAssembly.Instance.instantiateFromModuleSource [17:04:15.0353] this was where I was wondering if we might be able to define an internal slot on `WebAssembly.Module` that provided this relation in an internal way to 262 [17:04:21.0465] that could then be incorporated into the esm integration [17:04:41.0138] yeah, where does the `instanceof` requirement come from [17:04:48.0536] it could be a deep-ish sense of duck typing [17:04:51.0203] or the wasm js api [17:05:48.0139] Yeah, I was not precise. I specifically mean that x be a “module source” if it could later be passed to `new Module(source, ...rest)` and the prototype chain is not material. [17:06:23.0132] ah, then i think that is possible [17:06:29.0256] And I’ve got slides in the overflow that `source` should fall through to a protocol. [17:07:12.0854] For user virtualized module sources. That’s the escape hatch for defining bindings for, say, CommonJS in userspace. [17:07:54.0722] So, yeah, stuffing an internal slot on `WebAssembly.Module` such that it could be digested by `new Module()` is acceptable to me. [17:08:17.0024] Not just acceptable, a condition of my acceptance. [17:08:59.0370] And guybedford we can punt on how to link ESM into a JS graph. That’s answered https://github.com/WebAssembly/esm-integration/tree/main/proposals/esm-integration [17:10:13.0036] At least, I trust it does. [17:10:19.0486] my hope was not to have to flesh out such a protocol as a stage 2 requirement here by treating it as somewhat under-specified for now [17:10:29.0690] but if the feedback is to more clearly work this through we can investigate options [17:10:59.0984] I think the protocol likely belongs in the spec for the module source object [17:11:22.0187] For stage 2, I can be satisfied if we know we’re not painting ourself into a corner, regardless of what’s captured in the proposal text. [17:12:01.0916] The protocol for virtual modules is orthogonal and I only point it out because I expect the Module constructor to have overloads on its `source` argument. [17:12:49.0858] Which is to say that it can brand check for `ModuleSource`, then brand check for `WebAssembly.Module`, then fall through to a virtualized module protocol. [17:14:27.0968] The other wrinkle is that implementing a bundler or file watcher for all this is substantially easier of all “module source” types have a uniform way to access the module source’s list of import specifiers. [17:15:11.0898] As currently sketched, `moduleSource.bindings` is the same shape for `ModuleSource` and the protocol for virtual module sources. [17:21:15.0699] > <@kriskowal:matrix.org> Which is to say that it can brand check for `ModuleSource`, then brand check for `WebAssembly.Module`, then fall through to a virtualized module protocol. Or rather, check for [[StaticModuleRecord]] internal slot, which the former two would have. [17:21:44.0096] Yeah so the WebAssembly way of doing this is quite unique - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WebAssembly/Module/imports [17:22:24.0495] Yeah, we’ve discussed a protocol oriented around source.constructor.imports(source), which we agreed would be Special™. [17:22:35.0365] * Yeah, we’ve discussed a protocol oriented around `source.constructor.imports(source)`, which we agreed would be Special™. [17:26:08.0919] Is there a reason that `WebAssembly.Module.prototype` couldn’t have a `bindings` accessor to throw bundlers a bone? [17:28:02.0228] I don't know, if we're adding branding in theory we could add other things, Dan might know more about what's involved here since he did a lot of the JS API spec work I believe [17:29:38.0267] Well, I owe you a review, and I’m at least oriented. I can leave a note. [17:30:02.0060] Thanks for playing Wheel of Spec Fiction™. [17:31:35.0134] haha sure we've covered a lot! will take the winnings for now indeed [17:33:21.0310] I have just noticed the pun in spec fiction. Who’s responsible for this!)/ [17:37:01.0485] well we just call it specification I guess to begin with :P [18:00:57.0227] I mean, this is clearly a pun on SpecFic, the category containing both Fantasy and SciFi https://en.wikipedia.org/wiki/Speculative_fiction [19:50:17.0083] guybedford Luca Casonato I provided a review. I think it would be good to settle the question before plenary, whether a reflected module captures a module instance or a module source instance. I am pretty sure it must be the latter and the front matter for the proposal states the former. https://github.com/tc39/proposal-import-reflection/pull/21#pullrequestreview-1030806802 [21:28:50.0814] Kris Kowal: I think it would align with Wasm better if the JS reflection can be treated as supporting arbitrary linkage as opposed to only host linkage [21:29:06.0503] Since that is effectively what you get with `WebAssembly.Module` so that would be the symmetric choice [21:29:13.0708] I'm open to the representation options though [21:29:23.0378] at the moment that object is still a big `?` [21:29:43.0083] thanks for the review, I've pushed some updated, do take another look if you have a moment [21:33:39.0750] > <@guybedford:matrix.org> Kris Kowal: I think it would align with Wasm better if the JS reflection can be treated as supporting arbitrary linkage as opposed to only host linkage I’m not sure what this means. What’s the limitation of what? [21:34:18.0272] Kris Kowal: a `WebAssembly.Module` has imports in its binary [21:34:26.0928] which are not yet satisfied and can be linked against arbitrary importers [21:34:33.0746] * which are not yet satisfied and can be linked against arbitrary dependencies [21:34:52.0421] So the natural choice would be to aim for symmetry on that with the JS side [21:35:13.0654] That a JS reflection would not resolve its imports yet, but could still be instrumented against arbitrary dependencies [21:35:25.0803] depending on what hook is passed [21:35:38.0493] we could of course break that symmetry [22:00:26.0122] That’s consistent with my interpretation of a module source. [22:02:04.0874] That multiple `Module` instances can use a common source and link in different ways according to the provided `importHook`. [22:03:30.0067] Caridy’s `Module` object is very similar to the `ModuleInstance` you proposed at the last plenary. The big difference is that dynamic import kicks off the loader / linker, and that uses the import hook to discover the linkage. It has the nice property that a single hook can be used for both static and dynamic import. [22:04:06.0503] So instead of having to provide an `importHook` for dynamic import and a `link` method for static import, you just have `importHook`. [22:04:47.0754] And the small difference is that each `Module` instance has an independent memo for the results of `importHook`. [22:05:20.0978] It doesn’t account for assets and module reflection though, so I imagine we’ll have to revisit that. [22:09:33.0902] one step at a time I guess [22:10:06.0596] Yeah, assets and import reflection imply a different design for virtualized host hooks on `Module`. More like `fetchHook(specifier, importMeta) => Promise` followed by `reflectHook(bytes, reflectionType) => unknown` [22:10:42.0325] right, I want to put some more thought to the cache questions in due course as well around this for reflection [22:10:59.0231] for now it's explicitly flagged as a spec todo to define the exact cache behaviours [22:11:50.0395] I must say in the quiet of my heart that I’d hoped that virtualized module sources and externalizing the concern of interpretation such that each module has exactly one reification would put the issue of assets to bed. [22:13:17.0413] And this wakes the old MIME-type / extension mismatch issue that drove import assertions into its current shape. [22:13:46.0930] So, perhaps reification of module source is special and not general. [22:14:35.0488] But even then, the host hooks have to separate loading from instantiation. [22:16:18.0084] e.g., `loadHook(specifier, importMeta) => Promise` and `importHook(source, importMeta) => Module`. [22:22:08.0732] the hope is to leave the internal invariants and host hooks in a better state that we found them [22:22:18.0549] I think between the specs that is achievable [22:22:25.0939] but it will take some formalizing yet [04:29:46.0215] > <@guybedford:matrix.org> @littledan thanks for the feedback, we see module reflection as laying down an approach that asset reflection and deferred execution can follow in, as opposed to the original more abstract view of a generical mechanic. Trying to be practical and use case focused while treating generalization as a possibility but not to over-generalize. We are keen to see asset references and deferred module loading move forward, we are just trying to focus our efforts in a way that keeps scope clear in the staging process. We currently are underspecifying what exactly the shape of the reflection object is though, and treating this as a detail to be refined as opposed to prescribing it at this point. The way we do this for now is to entirely delegate it to a host hook, then the hope for Stage 3 would be to follow-up with an exact definition for JS that will hopefully have progressed by then. We need the host hook regardless for Wasm though. Yes, going incrementally via the stage process seems generally good, but could you say more about why you decided to make the cut here exactly? I mean, presumably the host hook underspecification approach you describe would work just as well for asset references. Are there particular anticipated sources of complexity from asset references that you see as simpler for module reflection? [04:32:16.0793] > <@kriskowal:matrix.org> My feeling is that trusting the sender and receiver to have identical importHook behavior is possible but fragile. But, if we have blocks, static blocks, `Module` and `ModuleSource` to work with, I think that the ecosystem will have everything it needs to come up with more sensible protocols for sending modules to workers. In the web, I’m not sure if we need any “trusting” here: the hooks simply are the same for native modules, and maybe we should just throw a DataCloneError if you try to serialize a Module with any other importHook [04:34:44.0785] > <@kriskowal:matrix.org> That is to say, I predict that `worker.import(module {})` will look good in examples but will otherwise have limited utility. But, that’s okay with me. Well… this is much of the stated motivation of the proposal that Surma and I presented to committee and that the committee agreed to Stage 2 on. I am surprised to see so much skepticism on this point and interesting in understanding more about why you feel this way; I wonder what went wrong in communication that we didn’t uncover this disagreement sooner. [04:37:51.0190] Wasm itself prohibits module import cycles, but the Wasm ESM integration proposal is designed to permit them between JS and Wasm… but maybe it does so in too flaky of a way [05:01:05.0384] I guess now that I hear more about how the caching for the import happens within the Module, rather than a single Module producing a separate instance somewhere else… I understand why you all have been calling this construct ModuleInstance over the years [07:44:03.0294] I'm re-reading the slides Kris Kowal presented yesterday, and I have a question. In the example with a custom module source, I see that the `initialize` method receives `importMeta`. Does it also receive `importHook`? I'm trying do understand if/how Source Text Static Module Records could be expressed in terms of Virtual Static Module Records. For example, how could I create a custom module source that uses my own ecmascript engine and delegates module loading to the ecmascript host it's running in? [07:59:24.0905] I think the answer is yes. JavaScript module sources can be virtualized. It’s also possible to implement `ModuleSource` as an object that satisfies the virtual module source protocol. But, I imagine that would come at a performance cost that isn’t acceptable. [08:01:31.0444] For JavaScript to JavaScript bindings, I think engines are free to implement linkage as literal pointers to shared slots. Through the virtual module source protocol, reading and writing bindings would have to pass through the module imports namespace exotic object, which would be slow on top of slow. [08:02:16.0958] > But, I imagine that would come at a performance cost that isn’t acceptable. Yes, I was thinking about something like eshost rather than a production thing. [08:02:31.0070] You’re right that `initialize` needs to receive a dynamic import function. It would also have to be the one bound to the module instance’s memo. [08:03:19.0416] And providing either `importMeta` or `dynamicImport` can be contingent on whether the module declares that it needs them with `needsImport` and `needsImportMeta` on its module source object. [08:03:28.0278] So, an options bag. [08:03:54.0227] I believe they can also participate in cycles. [08:04:18.0938] The module imports namespace object was an idea that the folks on XS came up with. [08:04:22.0468] It’s quite clever. [08:04:50.0694] And they implemented it, and it works, so my confidence in the idea is pretty high. [08:04:54.0138] I guess my custom module source would also have to know how the import hook works, because it might need to pass a custom `importMeta` object when calling `importHook` to make sure that the "base URL" is correct and not the one of the entrypoint module. [08:05:55.0890]