TC39 Module Harmony on 2023-03-28

12:25	<Jack Works>	🤔
12:26	<Jack Works>	implementing "assert { webpackSync: true }" in webpack
12:26	<Jack Works>	asserts the module graph does not contain TLA or Async WebAssembly module
12:27	<Jack Works>	but asserts have been deprecated, and the "with" keyword does not fit the semantic of this feature.
12:28	<Jack Works>	any suggestion? does that mean assert itself has its meaning? or should I rename it to "with { webpackAssertSync: true }"?
12:29	<svensauleau>	Using `with` the key could express the assertion. What about `with { webpack: { ensureSync: true }}`?
12:29	<Jack Works>	Note: I also found no boolean literal is allowed which is annoying. I have to use `"true"` instead of `true`
12:29	<svensauleau>	another alternative could be `with { webpack: { sync: 'ensure' }}`
12:31	<Jack Works>	Using `with` the key could express the assertion. What about `with { webpack: { ensureSync: true }}`? oh... that's also an option, but webpack internal does not have the evaluation of object literals means it will be a lot more work for me to do this
12:32	<Jack Works>	for multiple attributes provided by the same tool chain, does the proposal champions recommend "webpackX: val, webpackY: val" or nested "webpack: { x: val, y: val }"?
12:33	<svensauleau>	there was a discussion about that but I don't remember the outcome. I think we should support `with { webpack: { ... }}`.
12:44	<littledan>	Currently only strings are supported
12:45	<littledan>	For multiple webpack-defined keys, you can use `with { _webpackFoo: “xyz”, _webpackBar: “abc” }`
12:45	<littledan>	We should probably do more ASAP to document and socialize this convention
12:46	<littledan>	I don’t think we should be adding features right now; we just had a period of reconsideration and explicitly decided to keep the expressiveness of values the same
16:01	<nicolo-ribaudo>	Meeting now?
16:02	<Kris Kowal>	I’m still away and tending to a newborn and toddler, but I’m very much interested in summaries if someone has a moment to describe progress/regress from plenary or today’s module meeting.
16:03	<Luca Casonato>	I'm sitting in the waiting room - no-one else around to join today?
16:04	<nicolo-ribaudo>	I'm sitting in the waiting room - no-one else around to join today? Same
16:07	<nicolo-ribaudo>	Most significant updates: import assertions are back to Stage 3 (conditional on editors reviews) as "import attributes", without the constraint that they cannot affect loading and cannot be part of the cache key Luca and Guy gave a presentation in plenary about the various phases of loading a module, from resolution to evaluation, showing how different proposals are just "stop at an early phase" Guy is thinking about possible design suggestions to compartments Layer 0 to work around some of the feedback given in the November meeting
16:08	<guybedford>	unfortunately I don't have permissions either, also in waiting room...
16:08	<Luca Casonato>	Luca and Guy gave a presentation in plenary about the various phases of loading a module, from resolution to evaluation, showing how different proposals are just "stop at an early phase" I think the presentation was well received. We have some feedback from Jordan to think about return types for "source" phase imports, but we think we can tackle this and attempt Stage 3 at next plenary.
16:09	<Luca Casonato>	To join the video meeting, click this link: https://meet.google.com/afs-kzui-qsx Otherwise, to join by phone, dial +31 20 257 4432 and enter this PIN: 775 821 400# To view more phone numbers, click this link: https://tel.meet/afs-kzui-qsx?hs=5
16:09	<Luca Casonato>	let's just use a different room then :)
16:10	<littledan>	(I'm skipping this meeting but I can briefly join to let people in if needed)
16:10	<Luca Casonato>	littledan: we've figured it out
16:11	<Luca Casonato>	guybedford: new link, can you join there?
16:36	<annevk>	Nice work on Import Attributes, btw!
16:44	<Luca Casonato>	Mathieu Hofman: https://crbug.com/567999
17:03	<Luca Casonato>	What do you all think about making the loader meeting 1 hour again, but doing it weekly rather than bi-weekly? Please vote below:
17:22	<littledan>	Luca and Guy gave a presentation in plenary about the various phases of loading a module, from resolution to evaluation, showing how different proposals are just "stop at an early phase" I think the presentation was well received. We have some feedback from Jordan to think about return types for "source" phase imports, but we think we can tackle this and attempt Stage 3 at next plenary. Is the proposed solution described anywhere?
17:23	<littledan>	I really think we need a general set of built-in type-checkers similar to isArray, as was previously proposed. I don't think it's optimal that we're doing this case-by-case (it comes up for many proposals).
17:37	<nicolo-ribaudo>	Jordan's concern here was not "that thing has an internal slot we cannot check", but "that thing has no internal slot to uniquely describe it as the result of import reflection"
17:48	<littledan>	I really think we need a general set of built-in type-checkers similar to isArray, as was previously proposed. I don't think it's optimal that we're doing this case-by-case (it comes up for many proposals). please don't give too much importance to this comment; I'm fine with a specific solution for this case, for now.
19:48	<Luca Casonato>	that thing has no internal slot to uniquely describe it as the result of import reflection Which I think it will - the internal slot that will be used by the `new Module()` constructor to figure out what it is meant to do with a given source.
19:49	<littledan>	So, what's the proposed solution? Do we create a predicate specifically for this, or do we say it will be solved when we later add `new Module`, or what?
19:49	<littledan>	or do we add `new Module` already?
19:50	<Luca Casonato>	That I am not sure on yet - ljharb: would you be OK with the predicate being the `Module` constructor itself?
19:50	<Luca Casonato>	We still have 6 weeks to figure it out :D
19:52	<ljharb>	how would that work?
19:52	<ljharb>	like new Module throws unless it has a single argument that’s a module source instance, and creating a Module has no immediate side effects?
19:52	<Luca Casonato>	if `new Module(source)` throws it is not a source, if it does not, it is a source
19:52	<Luca Casonato>	creating a module has no side-effects
19:52	<Luca Casonato>	evaluation only happens when you call `await import(module)`
19:53	<ljharb>	seems fine to me. How can i synchronously detect what’s a Module instance? :-)
19:54	<littledan>	I agree that the `Module` constructor would naturally throw if passed a non-source thing. and it'd return a Module instance directly, not a Promise, so no need to worry about asynchrony.
19:54	<littledan>	We could also have a Module constructor which initially doesn't allow an importHook, but this would still maybe not be the best, as the idea for Wasm source imports is that it then wouldn't pull in Wasm/ESM integration
19:54	<Luca Casonato>	`Module.isModule()`? 😆
19:56	<Luca Casonato>	What do you mean by that? I'd expect Wasm/ESM integration to happen if we ship import reflection. Wasm source import reflection without Wasm/ESM integration seems very weird 😃
19:57	<littledan>	well, there had previously been a lot of doubt about whether importing Wasm all the way, directly, was useful for anyone at all. The argument was made that source imports are more useful, and that direct Wasm imports would only really work well with "the component model" or something similar to do the glue code for you
20:13	<Luca Casonato>	I think there are use-cases where it works fine
20:13	<Luca Casonato>	The WASM just needs to be compiled specifically for JS
20:13	<Luca Casonato>	namely imports in the wasm need to be relative JS specifiers
20:14	<littledan>	well, just relative paths in general (to JS or Wasm)
20:14	<Luca Casonato>	the problem is that "arbitrary" wasm (ie compiled for WASI) would not work well
20:14	<Luca Casonato>	right that's what i mean. don't know why i said "JS specifiers" lol
20:14	<Luca Casonato>	i'd still like to ship wasm/esm in Deno soon
20:15	<littledan>	I think something which would help is, demonstrations of use
20:15	<littledan>	WebKit and SpiderMonkey have Wasm/ESM integration largely implemented, and are just holding back on whether it's useful
20:15	<littledan>	(IIRC)
20:15	<Luca Casonato>	but i need Chromium to agree to ship it at the same time. unfortunately I was the one that told them that we should probably all hold off until we had wasm source imports. sorry!
20:16	<littledan>	did Chromium even start implementing it?
20:16	<Luca Casonato>	i had a call with shu and 2 chrome engineers
20:16	<Luca Casonato>	but i don't think that went anywhere
20:16	<littledan>	but i need Chromium to agree to ship it at the same time. unfortunately I was the one that told them that we should probably all hold off until we had wasm source imports. sorry! I think this was reasonable since we didn't know at the time that it would be possible to separate source from instance imports
20:16	<littledan>	i had a call with shu and 2 chrome engineers When was this?
20:17	<littledan>	but i don't think that went anywhere If it was a year or two ago, I think you successfully convinced them that Wasm/ESM integration was not useful in practice--that's the takeaway that I got out of conversations with them.
20:17	<Luca Casonato>	we did implement it largely in Deno (without changes to V8), but then ran into issues with V8 synthetic modules that need to be async
20:17	<Luca Casonato>	it was 24 May 2022
20:18	<littledan>	oh OK I guess they were convinced that Wasm/ESM integration wasn't useful earlier than that
20:19	<Luca Casonato>	I never said it was not useful in practice - just that source imports would be more powerful from the get go. asumu was also on this call. Now that we know we can do both, we should probably re-visit
20:19	<Luca Casonato>	I think it's safe to do Wasm/ESM now because we can do both source and instance import
20:19	<littledan>	I didn't say that you said that, but this seems to be their current impression
20:20	<Luca Casonato>	Yeah, just clarifying what I said on the call :)
20:20	<littledan>	anyway yeah I think we have the conflict resolved, but we also shouldn't block shipping one on the other (since it will be less work to ship just source imports)
20:21	<Luca Casonato>	But if it's essentially done in WebKit and Gecko, we should just ship it. asumu you we're working on pushing this - is this still something you're pursuing?
20:21	<littledan>	I was so nervous about all of this ~8 months ago; I'm really glad that we're so close to a resolution
20:21	<Luca Casonato>	Yeah, and I think the solution is pretty elegant also :)
20:23	<littledan>	But if it's essentially done in WebKit and Gecko, we should just ship it. asumu you we're working on pushing this - is this still something you're pursuing? Previously, Asumu was doing this work on contract with Bloomberg. At this point, if we're talking about 1-2 weeks of effort from here, I think we can squeeze it into our tab. More would probably be too much of a tangent to be funded by us (but maybe Asumu is independently motivated, hint hint guybedford)
20:27	<asumu>	Yes Wasm ESM source imports was mostly done in WebKit, but it's been on pause for a while in terms of work on the spec and finishing the implementation. Not sure if I will have time to work on it currently.
20:27	<littledan>	asumu, was your work in WebKit or Gecko, I forgot
20:27	<asumu>	It was in WebKit, yeah.
20:27	<littledan>	maybe there is no Gecko implementation and just WebKit
20:28	<asumu>	I suspect Gecko doesn't have it, but not sure.
20:28	<littledan>	yeah I'd suspect the same
20:28	<littledan>	anyway Constellation was almost up for shipping it in the past, right?
20:31	<asumu>	They were definitely happy to accept patches on it anyway, though we didn't discuss shipping it yet. He was also working on import assertions implementation in WK too IIRC, and wanted to know how those would work together too.
21:21	<ljharb>	sgtm :-p
21:28	<littledan>	I think the idea was: WebAssembly is not marked differently, since long-term we want JS to be redone in Wasm without changing how it's invoked
21:28	<littledan>	but we should discuss this more explicitly at some poitn
22:40	<guybedford>	all sounds quite sensible to me