| 20:26 | <Kris Kowal> | nicolo-ribaudo guybedford I just dropped a comment, but if discussion is warranted, I’m reminded that we at Agoric insist that all new intrinsics be reachable from globalThis by transitive property walk, until another proposal advances far enough that we’re confident we can reach all intrinsics another way. |
| 20:27 | <Kris Kowal> | So, I suggest keeping globalThis.ModuleSource in Import Parse Phases even if it’s otherwise inert. It also serves as the anchor for ljharb’s brand check accessor in environments in which WebAssembly.Module does not exist. |
| 20:28 | <Kris Kowal> | So it would not be constructible but would not be useless. |
| 20:31 | <littledan> | What does this mean? "Phase syntax by convention, not specification" |
| 20:31 | <littledan> | (from Lucas&Guy's slides) |
| 20:34 | <Kris Kowal> | My team also just let me know while I was away that they decided that they wouldn’t object to import.source, import.module, &c syntax even though it would break old versions of our SES lockdown shim, but we also won’t push for a change on the eve of a call for stage 3. |
| 20:35 | <littledan> | I significantly prefer the syntax in the current proposal FWIW |
| 20:35 | <littledan> | but separately, didn't we want to provide some kind of access to AbstractModuleSource from the global? |
| 20:35 | <Kris Kowal> | I figured that it would be preferred. 👍 |
| 20:37 | <Kris Kowal> | In the PR, Guy, Luca, and Nicolò have been waffling on whether to have some kind of global access to AbstractModuleRecord and it hasn’t settled yet. https://github.com/tc39/proposal-import-reflection/pull/36 |
| 20:38 | <Kris Kowal> | I erroneously stated no strong preference. We do want the new intrinsics to be accessible. I think the champions are otherwise on the fence at the moment. |
| 20:38 | <littledan> | tbh for something going to Stage 3, it'd be ideal if all the spec text landed by the agenda deadline |
| 20:39 | <Kris Kowal> | I also expect the problem to heal naturally when some subsequent proposal makes ModuleSource real. |
| 20:42 | <littledan> | For something to go to Stage 3, I'd hope the presentation also explains these sorts of details which are apparently still under debate (like sourceText vs @@toStringTag). Maybe this meeting should be more of a "call for final review" |
| 20:44 | <guybedford> | Kris Kowal: yes, at least if we ship Wasm first, then WebAssembly.Module will provide AbstractModuleSource reachability through the WebAssembly global. |
| 20:44 | <Kris Kowal> | Is WASM shipping in 262? |
| 20:44 | <Kris Kowal> | There will be environments in which WebAssembly will not exist but AbstractModuleSource will. |
| 20:45 | <guybedford> | @littledan the PR was ready and reviewed last week. nicolo-ribaudo just has lots of editorial feedback. I'd argue a lot of the remaining questions are editorial, apart from the global ModuleSource point of course which Luca only brought up on Friday unfrotunately |
| 20:45 | <guybedford> | Kris Kowal: in such environments, AbstractModuleSource would be unreachable |
| 20:46 | <guybedford> | but yes, I did bring this whole argument up to Luca when he suggested it |
| 20:46 | <guybedford> | his argument was that global.ModuleSource being useless seems an untennable thing to ship |
| 20:47 | <guybedford> | and he was concerned about getting agreement on that |
| 20:47 | <guybedford> | in that we should ship features that have, well, features |
| 20:49 | <littledan> | @littledan the PR was ready and reviewed last week. nicolo-ribaudo just has lots of editorial feedback. I'd argue a lot of the remaining questions are editorial, apart from the global |
| 20:50 | <littledan> | at the same time, this is the first meeting where the champion group will be presenting the newly concrete scope (Wasm source modules) and the final syntax (with the excellent explanation in terms of loading stages) to the committee. It might be best if we present this to committee this meeting, let it sink in, call for more reviews, and propose advancement next meeting (unless there is some reason for more urgency that I can't see) |
| 20:52 | <guybedford> | The main point of urgency I feel at this point is just that if we know which spec gets to stage3, then the layering questions all start to fall out much more easily from there |
| 20:52 | <guybedford> | because already there's a lot of cross-over in the spec text |
| 20:54 | <littledan> | Yeah editorial churn is definitely costly but I think it shouldn't really affect decisions like this ideally. I don't think this should wait more than 1 meeting though. |
| 20:56 | <littledan> | and we're still going back and forth among this group about key questions, like should this contain an inert ModuleSource. We should strongly settle on decisions to get to Stage 3. |
| 21:00 | <Kris Kowal> | At least, I think this is the last open question and it’s not that hard to settle. I expect we’ll have all important decisions settled by end of meeting tomorrow. |
| 21:00 | <Kris Kowal> | Emphatically eager to see this go forward as soon as possible. |
| 21:25 | <littledan> | Do we expect to ever have hook-ability for asset references? |
| 21:33 | <Kris Kowal> | I expect we will. |
| 21:33 | <Kris Kowal> | And I think that door remains open with the proposals as they stand. |
| 21:35 | <Kris Kowal> | My intuition is that we’d introduce importAssetHook to the Module constructor option which would bypass importHook and return a new ModuleAsset type. The ModuleAsset would have a hook for producing one or more sources or modules. |
| 21:35 | <Kris Kowal> | Or mechanisms to that effect. |
| 21:39 | <littledan> | yeah that makes sense, and then the normal import pipeline will call both hooks |
| 21:39 | <Kris Kowal> | Assuming import assets would express their entire cache key up front (be orthogonal to import attributes), there probably would either be a single corresponding ModuleSource or no corresponding module source at all, so there might instead just be a hook for getting the bytes and an optional behavior for promoting it to source. |
| 21:40 | <Kris Kowal> | My thought was actually that only one hook or the other would be used. |
| 21:40 | <littledan> | well, if there's a hook for getting the bytes, it should include the attributes |
| 21:41 | <Kris Kowal> | That is, if you provide an importAssetHook, it would take precedence over the importHook. |
| 21:41 | <Kris Kowal> | The importHook doesn’t have the signature necessary to chain the result of the importAssertHook. |
| 21:42 | <littledan> | how so? |
| 21:42 | <Kris Kowal> | Consider a very different straw-design: The importAssetHook would just return bytes and parseAssetHook which accepts the bytes and returns a Module. |
| 21:43 | <Kris Kowal> | Both would receive the same attributes bag. |
| 21:43 | <littledan> | I think assets are URLs on the web and really don't correspond to bytes |
| 21:44 | <Kris Kowal> | Ah, I must be misinterpreting the intent. If Asset is an opaque token that captures the location of the resource, that’s an even earlier phase than I imagined. |
| 21:44 | <Kris Kowal> | Though, in a bundler, it would necessarily capture the underlying source and maybe even the bytes. |
| 21:47 | <Kris Kowal> | To avoid my confusion, perhaps what we’ve been calling Asset would be better described as either a Content or Location import phase. |
| 21:49 | <Kris Kowal> | In any case, I don’t think anything in the import phase or import attributes proposal is likely to be regretted in the face of language evolution toward import assets. |
| 21:51 | <Kris Kowal> | Also unlikely that anything about module import virtualization would be regretted, but I can imagine a design where the import hook can’t ignore the asset phase. |
| 21:59 | <Kris Kowal> | The location phase would be problematic for portability, but a resolved phase is okay. That’d be analogous to the Compartment resolveHook. |