2023-06-01 [05:42:33.0722] ✌️Macros✌️ https://bun.sh/blog/bun-macros 2023-06-05 [11:25:20.0975] Module harmony agenda is empty for tomorrow. Come one, come all, please scribble a topic in https://docs.google.com/document/d/1CD5lIBZLl24XBWbQhokqBdt4Zl7wPAcFJKJrgePr9HU/edit# [16:15:07.0090] I won't be able to make the meeting tomorrow myself, but will be able to resume again next week [16:41:36.0510] I will miss it too (due to the Igalia web engines hackfest, where Nic gave a great talk that you can see at https://www.youtube.com/live/_yFkay2pQBA ) 2023-06-06 [17:01:41.0120] Apparently the custom elements people are thinking of making an HTML syntax for overriding what a specifier resolves to, see “Declarative CSS Module Scripts” at https://eisenbergeffect.medium.com/web-components-2023-spring-update-60c7873adf98 [17:02:19.0769] This is another possible solution in the space that module declarations (and CSS nested stylesheets) are operating [17:03:14.0009] I’m not sure if a follow-up issue was filed but I think we should try to stay in the loop here [02:41:38.0494] Nico, Dan, and me won’t be able to attend todays meeting [04:29:08.0127] Playing around with import attributes... https://github.com/nicolo-ribaudo/scoped-css-imports [09:02:31.0600] I’ll keep the door open for a while but we certainly don’t have quorum. [09:48:23.0457] (We did not convene) 2023-06-07 [13:58:19.0638] nicolo-ribaudo: that's a really interesting example! [13:58:25.0733] have you shown it to some of the css folks? [13:58:49.0011] perhaps Lea Verou would be interested as well? 2023-06-13 [09:01:13.0282] I'm a couple of minutes late [10:49:53.0718] > <@littledan:matrix.org> I will miss it too (due to the Igalia web engines hackfest, where Nic gave a great talk that you can see at https://www.youtube.com/live/_yFkay2pQBA ) This video is not playing for me. Not sure whether there’s another video, or if this is just broken for me and not other. Other videos work. [10:50:03.0291] > <@littledan:matrix.org> I will miss it too (due to the Igalia web engines hackfest, where Nic gave a great talk that you can see at https://www.youtube.com/live/_yFkay2pQBA ) * This video is not playing for me. Not sure whether there’s another video, or if this is just broken for me and not others. Other videos work. [10:50:27.0011] Works for me [10:53:29.0238] Sigh. [11:00:55.0781] Let me check, maybe I have a different recording somewhere [11:01:43.0762] https://www.youtube.com/watch?v=USQ6MOEn0Go [11:13:54.0702] This is working for me. Thank you! 2023-06-14 [20:36:29.0837] sorry guys, I could not make it today! 2023-06-16 [07:49:53.0897] For the tools meeting, we will only have 40 minutes because there is already another scheduled topic (V8's eager compilation hints) Romulo Cintra will send the agenda on Monday -- the event is on the TC39 calendar, but let us know if you want an invite :) [07:51:11.0057] * For the tools meeting, we will only have 30 minutes because there is already another scheduled topic (V8's eager compilation hints) Romulo Cintra will send the agenda on Monday -- the event is on the TC39 calendar, but let us know if you want an invite :) 2023-06-19 [10:09:22.0448] Proposing import with type text, bytes, or url https://github.com/whatwg/html/issues/9444 [10:09:32.0452] > <@nicolo-ribaudo:matrix.org> For the tools meeting, we will only have 30 minutes because there is already another scheduled topic (V8's eager compilation hints) > > Romulo Cintra will send the agenda on Monday -- the event is on the TC39 calendar, but let us know if you want an invite :) I intend to show up. 2023-06-20 [20:55:43.0361] I heard `import defer * as ns` has changed to `import defer ns` is that happening? [00:31:30.0793] No, where did you read it? [08:57:15.0291] I'll probably be 5 minutes late [09:00:10.0001] littledan: syntax for meta.resolve() or a different attribute makes a bit more sense to me than overloading `type` [09:01:23.0869] littledan: at least as currently specified we end up fetching everything with `type` and this `url` thing would create quite the code smell I think [10:00:01.0294] I don't remember us discussing overloading `type` much in this group. I agree that it's code smell to use that particular attribute. I'd at least use another key [10:00:47.0848] We've mostly discussed syntax like `import asset foo from "./foo.jpeg";` or something [10:01:06.0868] Kris didn't like that syntax because he found it ambiguous between whether `foo` was a URL or the bytes [10:01:20.0465] even if it's the bytes: we still need the type so that the fetch can be done properly [10:17:26.0128] Is `asset` bytes or URL in that case? [10:18:02.0769] Also, is the underlying Module paused before fetch or after? [10:20:44.0765] I presume that `import bytes from './bin.oct' with { type: 'bytes' }` implies a content-type of `application/octet-stream` and is as such sufficient to go as far as `fetch` especially, especially since there’s no possibility of advancing to evaluation behavior. [10:21:33.0941] I presume also that `import text. from './text.txt' with { type: 'text' }` implies a content-type of `text/plain; charset=utf-8` and is also sufficient to go to `fetch`. [10:24:16.0626] Whereas `import url from './image.jpg' with { type: 'url' }` implies nothing about the content-type and wouldn’t advance to `fetch` in any case. Using a different key introduces confusion about the role of `type` in `import asset imageUrl from './image.jpg' with { type: 'jpeg' }` (it would just produce a different memo key) [10:25:33.0494] Or, alternate strawpoke, `type` would be vestigial in `import imageUrl from './image.jpg' with { type: 'jpeg', phase: 'located' }`. [11:02:47.0527] Kris Kowal: I was thinking we might ignore the `Content-Type` response header for some of these types, as `fetch()` does. Requiring a `Content-Type` like CSS module scripts do would make them not as useful I think. [11:05:14.0881] Kris Kowal: why would it need `type` at all? `import url from 'test' with { gimme: 'url' }` [11:20:46.0770] The question is not whether the type is needed, but what it would mean if it happened to be provided. [11:23:17.0661] e.g., `{ gimme: 'url', type: 'css' }` and `{ gimme: 'url', type: 'json' }` would give you the same URL twice, but have two entries in the modules memo and do the work twice. Whereas, `{ type: 'url' }` would ensure only one memo entry. [11:23:28.0742] But this is a small thing I’m not hung up on. [11:28:57.0111] > <@kriskowal:matrix.org> Is `asset` bytes or URL in that case? URL. This is just more frequently useful than bytes, I think. [11:34:26.0832] `import.meta.resolve` has been adequate for me; I would be a little hesitant to introduce a second way of doing that [12:20:55.0004] Isn't `import.meta.resolve` intrinsically a dynamic API that wouldn't allow preprocessor / bundlers to understand and map which assets need to be part of a deployment artifact? There ought to be a reason that all bundlers currently go the `import './foo.css'` route to reference external assets. [12:24:56.0274] only if you use it in a dynamic way [12:25:23.0203] if the bundler is relying on it, it can easily error if you pass it a non-constant or factor it out into a variable [12:25:48.0488] at least part of the reason they all use the `import './foo.css'` syntax is because that decisions predates the existence of `import.meta.resolve` [12:26:12.0055] * at least part of the reason they all use the `import './foo.css'` syntax is because that design decision predates the existence of `import.meta.resolve` [13:52:35.0624] it also predates dynamic import. [15:08:30.0774] We could solve that by making an `import.resolve()` meta function [15:10:47.0159] But we should be able to support both as long as it explicitly matches `import.meta.resolve()` (or some trivial static analysis of `const meta = import.meta; meta.resolve()` 2023-06-21 [00:50:43.0910] Kris Kowal: I guess I'd also expect them to be mutually exclusive (either through an error or ignoring), but putting a request for metadata in the same namespace as a request for data feels weird [07:54:19.0529] `import.resolve` with consistent cross-platform behavior would be awesome [07:54:34.0103] there's currently some contention about sync vs async in browsers vs node iirc [07:55:31.0022] Node.js recently changed it to be synchronous to align with browsers [08:00:32.0263] right - which is "fine" in the sense that i prefer sync, but it's not fine in the sense that node needs it to be async for various reasons, and also in the sense that node doing something bad for node to align with browsers is hugely harmful for node imo [08:00:58.0319] * right - which is "fine" in the sense that i prefer sync, but it's not fine in the sense that node needs it to be async for various reasons, and also in the sense that node doing something bad for node to align with browsers is hugely harmful for node imo (whereas, if we work out the issues in the spec then they're all aligning with the spec, and that's good) [08:38:38.0892] were these reasons around the semantics of soft links? [08:38:49.0143] being the same cache key (vs different for HTTP redirects) [08:41:17.0720] They might have to do I/O to resolve, I think. I think they might have also followed symlinks? Very different specifier behavior. [13:29:57.0903] i don't recall the specifics [13:30:04.0720] for all i know the requirement was ideological instead of technical [14:19:54.0366] > <@ljharb:matrix.org> for all i know the requirement was ideological instead of technical Well, there never really is a bright line between those, is there [14:20:07.0855] indeed 2023-06-26 [03:59:59.0247] Hey, next week I cannot attend our meeting: if there is anything needed from me let me know so that we can talk about it tomorrow :) [04:00:15.0846] Also, next week the meeting will be on July 4th, so maybe also other people will not be available [12:06:17.0802] Yeah I doubt anyone in North America will be there next week. Speaking for Agoric, I expect no-one to be in attendance. [12:58:37.0786] Indeed, I am an Agoric person who will not be at Module Harmony on July 4. 2023-06-28 [08:52:12.0317] The tools meeting is in 10 minutes, with this agenda: https://docs.google.com/document/d/1RlnAnMa4QzQUK_tNOHdWfnske2X9KZ_e90VBG-DWqUo/edit [09:08:06.0950] (modules are in the second half)