TC39 Module Harmony
2026-03-20
plaintext logs
prev next
source on github
09:48
<nicolo-ribaudo>
We did discuss this a while ago, and I though the conclusion was that we cannot test that
09:48
<nicolo-ribaudo>
I mean, we cannot normatively require it, it's just "a suggestion"
09:49
<nicolo-ribaudo>
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
10:47
<guybedford>
right, but we can still test a non-normative requirement right? or rather a host requirement as opposed to a spec invariant that is?
10:57
<nicolo-ribaudo>

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

10:58
<guybedford>
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
10:58
<nicolo-ribaudo>
Yes I think testing on the concrete subclasses makes sense
10:59
<nicolo-ribaudo>
We should also make sure to test this in test262 for JS module sources
11:33
<guybedford>
right, I'll include it in that test rather
11:47
<Richard Gibson>
not only does that not invalidate the ability to test the original prototype, it defines a new scenario to be covered by testing
11:51
<nicolo-ribaudo>
But there is no requirement to test
11:54
<Richard Gibson>
maybe I'm misunderstanding the proposal... why would it not be a requirement?
11:55
<nicolo-ribaudo>
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
11:55
<Richard Gibson>
to allow for a deeper class hierarchy?
11:56
<Richard Gibson>
it can define initial state, though
11:56
<nicolo-ribaudo>
They can for example have WebAssembly.Module as their prototype rather than %AbstractModuleSource%
11:57
<Richard Gibson>
does WebAssembly.Module have that in its prototype chain, or is it fully independent?
11:57
<nicolo-ribaudo>
Yes it does
11:58
<Richard Gibson>
but there's no requirement of such? If not, why not?
11:58
<nicolo-ribaudo>

But consider example:

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

11:59
<nicolo-ribaudo>
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
12:00
<nicolo-ribaudo>
(not sure if that example is correct, assume it does whatever is needed to detach a parent class)
12:00
<Richard Gibson>
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
12:01
<nicolo-ribaudo>
Before being able to test something we need to define what normative requirement we are testing
12:01
<nicolo-ribaudo>
Which is what I claim we cannot define here
12:02
<Richard Gibson>
I see no reason why it cannot be defined. If the current text fails to define this, that seems like a problem
12:10
<nicolo-ribaudo>
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
12:11
<nicolo-ribaudo>
e.g. Node.js loaders
12:12
<Richard Gibson>
those are also user code that come after "initial conditions"
12:13
<Richard Gibson>

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

12:14
<nicolo-ribaudo>
Ok I was going through the defnition of Module Source Object, in https://tc39.es/proposal-source-phase-imports/#sec-module-source-objects
12:14
<nicolo-ribaudo>
This is indeed testable but it's too strict and the Wasm integration violates it
12:14
<Richard Gibson>
but apparently too strict if the actual requirement is "in the prototype chain" rather than direct prototype
12:14
<Richard Gibson>
the relaxation is still testable, though
12:15
<nicolo-ribaudo>
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"
12:16
<nicolo-ribaudo>
I think it's fine to require that it's the direct parent, as we don't know of more relaxed use cases
12:17
<Richard Gibson>
I would rephrase "When set" to "When not ~empty~"
12:18
<nicolo-ribaudo>
I am also reading "when set" as "when not ~empty~", but that's exactly the case where it's too strict
12:18
<Richard Gibson>
it's not too strict
12:18
<nicolo-ribaudo>
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
12:19
<nicolo-ribaudo>
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)
12:20
<Richard Gibson>
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"
12:20
<nicolo-ribaudo>

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

12:21
<nicolo-ribaudo>
Ok I think we are coming to an agreement
12:21
<Richard Gibson>
I think so too
12:22
<nicolo-ribaudo>
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