2026-03-19 [06:50:49.0721] Possibly silly question, I'm working on source phase imports, and I have a number of test failures that are related to GetModuleSource throwing a SyntaxError (e.g. https://github.com/tc39/test262/blob/a6f387de323eb9ae56448bdb71c5d315df631ce4/src/dynamic-import/import-source-source-text-module.case#L8), but I'm unable to find GetModuleSource in either the source phase imports proposal spec text, or the main spec. Has this been renamed or moved? [10:44:19.0895] This is from an old version of the spec yes - we changed it to be a slot on the module record instead, and this change was brought to committee and made in https://github.com/tc39/proposal-source-phase-imports/pull/69 [11:04:58.0348] Ok, yes, I do have that part implemented then, but I'm not throwing a SyntaxError. I take it that doing a source phase import on a JavaScript module should not set the [[ModuleSource]] slot for now, and then will end up throwing a SyntaxError because of it being empty? And that the `''` bit in test262 should produce something with the [[ModuleSource]] slot set for testing? [11:06:47.0408] > I take it that doing a source phase import on a JavaScript module should not set the [[ModuleSource]] slot for now, and then will end up throwing a SyntaxError because of it being empty? Exactly > And that the '' bit in test262 should produce something with the [[ModuleSource]] slot set for testing? Can you clarify what you mean by this? [11:14:31.0855] It's from this part, https://github.com/tc39/test262/blob/a6f387de323eb9ae56448bdb71c5d315df631ce4/INTERPRETING.md?plain=1#L166-L170 [11:16:42.0003] I haven't implemented wasm modules yet, but I can fake something for testing. [11:18:08.0336] yeah that makes sense. formally it's supposed to also have AbstractmoduleSource in the prototype chain as well, but I'm not sure if that is currently tested in 262? [11:18:24.0047] I can do a correction PR if not, including the correction for the [[ModuleSource]] slot - thanks for pointing these out [11:27:12.0845] Thanks for the clarifications. There are some tests for AbstractModuleSource itself (accessed through $262.AbstractModuleSource) but as far as I can tell, there's no tests verifying that the prototype is being set for `` modules correctly. [11:27:50.0506] ok I'll arrange a PR for those thanks for confirming [11:28:14.0645] np! 2026-03-20 [02:48:31.0215] We did discuss this a while ago, and I though the conclusion was that we cannot test that [02:48:53.0337] I mean, we cannot normatively require it, it's just "a suggestion" [02:49:30.0409] Because module A could do `import source s from "x"; Object.setPrototypeOf(s, {})`, and then when module B also does `import source s from "x"` it's obviously not going to have AbstractModuleSource on its prototype [03:47:18.0895] right, but we can still test a non-normative requirement right? [03:47:40.0869] * right, but we can still test a non-normative requirement right? or rather a host requirement that is. [03:47:57.0883] * right, but we can still test a non-normative requirement right? or rather a host requirement as opposed to a spec invariant that is? [03:57:31.0281] This is the phrasing in the proposal: > All Module Source Objects should have a prototype of %AbstractModuleSource%.prototype. If that "should" means "must" then yes, we can test it, but it's a requirement that hosts cannot respect unless they make module sources have an immutable prototype. If it means "it is recommended that" then we cannot test it, because an implementation ignoring that requirement would not be violating the spec [03:58:02.0911] * This is the phrasing in the proposal: > All Module Source Objects should have a prototype of %AbstractModuleSource%.prototype. If that "should" means "must" then yes, we can test it, but it's a requirement that hosts cannot respect unless they make module sources have an immutable prototype. If it means "it is recommended that" then we cannot test it, because an implementation ignoring that recommendation would not be violating the spec [03:58:17.0019] sure, that makes sense - in the WPT test cases we test this invariant for Wasm specifically where it's normative in the Wasm ESM Integration spec [03:58:40.0697] Yes I think testing on the concrete subclasses makes sense [03:59:24.0568] We should also make sure to test this in test262 for JS module sources [04:33:03.0864] right, I'll include it in that test rather [04:47:24.0245] not only does that not invalidate the ability to test the original prototype, it defines a *new* scenario to be covered by testing [04:51:39.0511] But there is no requirement to test [04:54:16.0163] maybe I'm misunderstanding the proposal... why would it not be a requirement? [04:55:16.0203] The proposal cannot require that those host-provided objects have a specific prototype chain when they go through that AO, because user code might have already manipulated it [04:55:28.0071] to allow for a deeper class hierarchy? [04:56:05.0518] it can define initial state, though [04:56:17.0972] They can for example have WebAssembly.Module as their prototype rather than %AbstractModuleSource% [04:57:30.0630] does WebAssembly.Module have that in *its* prototype chain, or is it fully independent? [04:57:39.0402] Yes it does [04:58:11.0950] but there's no requirement of such? If not, why not? [04:58:46.0860] But consider example: ```js Object.setPrototypeOf(WebAssembly.Module.prototype, {}); Object.setPrototypeOf(WebAssembly.Module, {}); // later, somewhere else import source s from "foo.wasm" ``` `s` will be born directly without AbstractModuleSource on its prototype [04:59:27.0675] So even if the wasm spec defines that WebAssembly.Module inherits from AbstractModuleSource, we cannot require that when instances of it are created they have the correct prototype chain [05:00:13.0020] (not sure if that example is correct, assume it does whatever isneeded to detach a parent class) [05:00:20.0221] * (not sure if that example is correct, assume it does whatever is needed to detach a parent class) [05:00:48.0436] so what? That's user code that would only be in a test that's covering its effects. The chain isn't that every new instance has a particular prototype chain, but that every new instance *in an unmodified environment* does [05:01:04.0220] * so what? That's user code that would only be in a test that's covering its effects. The claim isn't that every new instance has a particular prototype chain, but that every new instance *in an unmodified environment* does [05:01:17.0960] Before being able to test something we need to define what normative requirement we are testing [05:01:37.0715] Which is what I claim we cannot define here [05:02:44.0150] I see no reason why it cannot be defined. If the current text fails to define this, that seems like a problem [05:10:46.0882] Even if we define a property about its initial conditions, given that this is a host-defined object the host could create respecting the initial conditions and then process it before giving it to ECMA-262 [05:11:23.0063] e.g. Node.js loaders [05:12:07.0399] * Even if we define a property about its initial conditions, given that this is a host-defined object the host could create it respecting the initial conditions and then process it before giving it to ECMA-262 [05:12:13.0456] those are also user code that come after "initial conditions" [05:13:33.0136] https://tc39.es/proposal-source-phase-imports/#sec-abstract-module-records > When set, it [ [[ModuleSource]] ] must have a [[Prototype]] internal slot containing an object whose initial [[Prototype]] is %AbstractModuleSource%. this is testable [05:14:05.0743] Ok I was going through the defnition of Module Source Object, in https://tc39.es/proposal-source-phase-imports/#sec-module-source-objects [05:14:22.0838] This is indeed testable but it's too strict and the Wasm integration violates it [05:14:39.0936] but apparently too strict if the actual requirement is "in the prototype chain" rather than direct prototype [05:14:57.0402] the relaxation is still testable, though [05:15:35.0158] Unless "when set" means "at the time this field was first set this condition was true, but even if the field stays set the condition might not hold anymore" [05:16:20.0252] I think it's fine to require that it's the direct parent, as we don't know of more relaxed use cases [05:17:28.0292] I would rephrase "When set" to "When not \~empty~" [05:18:00.0892] I am also reading "when set" as "when not ~empty~", but that's exactly the case where it's too strict [05:18:21.0236] it's not too strict [05:18:21.0369] Because if user code modifies that object, than the field is not empty but it stays set to an object that does not respect that description [05:19:44.0743] It could be "when not ~empty~, [[ModuleSource]] must have a [[Prototype]] slot that **initially contained** an object whose initial [[Prototype]] is %AbstractModuleSource%" (bold the addition) [05:20:08.0940] the description is "an object whose **initial** [[Prototype]] is %AbstractModuleSource%". By definition, user code is incapable of violating it (because user code runs after anything specified as "initial" [05:20:49.0149] There is a chain of three objects here: 1. The module source 2. its prototype 3. the prototype's prototype Right now the "initial" requirement is only about 2->3 and not 1->2 [05:21:29.0707] Ok I think we are coming to an agreement [05:21:41.0121] I think so too [05:22:14.0295] That requirement should be relaxed to describe the _initial_ state of both links, and then it's actually possible for hosts to respect it and we can test it 2026-03-25 [16:06:50.0664] already a packed agenda for the module harmony meeting tomorrow, but please still feel free to add any additional agenda items and we can let the optional ones fall out to next time as well 2026-03-26 [09:49:01.0337] Seems like a memory leak in meet has killed my browser, trying to recover. [09:55:36.0189] guybedford: totally crashed, sorry [10:03:24.0273] Lost the local recording to a reboot (partial file was in /tmp) 😔 [10:10:01.0357] BTW, slides of my presentation is here https://docs.google.com/presentation/d/1-AXcjt0W6VFsA10DkBitn2MRRKOUTqrW7fVqiQbA8ZI/edit?slide=id.g3965d76ffd6_0_41#slide=id.g3965d76ffd6_0_41. Also the PR I mentioned is this one https://github.com/tc39/proposal-deferred-reexports/pull/29 [10:10:24.0711] Thanks all for your time and sorry for missing the initial 15 min. [10:39:42.0521] Not a major problem, but thank you for trying! [10:41:38.0718] nicolo-ribaudo: there are only some very brief notes on the agenda, so it may be better to sync with Caio Lima for a summary of the meeting