Repository navigation
Integration with import attributes #42
Description
Now that import assertions are Stage 3, we have to decide how they will integrate with Wasm/ESM integration. There are two aspects of this:
- When importing a Wasm module from JS, does it need an explicit
assert { type: "wasm" }or is this OK to be implicit (given that, currently, JS and Wasm run at the same privilege level Should WebAssembly be at the same "privilege level" as JS? #41)? - WebAssembly modules will need a custom section which somehow note the import assertions. We'll want to design this custom section format to be future-proof to possible expansions of the import assertion grammar, and the possible creation of "evaluator" attributes. (previous mention)
Activity
devsnek commentedon Nov 11, 2020
I think need should be no, but an implementation should feel free to add that.
littledan commentedon Nov 11, 2020
I guess there are two questions:
In HTML, implementations don't really have the freedom to add things--HTML is governed by a standard. We could make this mandatory, optional, or always missing, when used in HTML. But we won't let each individual browser choose its semantics.
Other environments can sort of do whatever they want--they don't have to align with HTML, or they can align but also permit looser behavior.
annevk commentedon Nov 30, 2020
Do we envision the capabilities of Wasm and JS to diverge? If so, requiring an assertion might be prudent.
Ms2ger commentedon Nov 19, 2021
When importing a Wasm module from JS, I don't think there's any reason to allow an import assertion, since the Wasm module can import other JS anyway. It remains possible to forbid that by using
WebAssembly.instantiate()directly.If we'd ever want to add a feature where JS imports Wasm that can't then import JS (though I don't see why we'd want to do that), we could use an import assertion for that - and it would be unfortunate if the obvious string was already taken here.
Import assertions for wasm importing json (for example) are an orthogonal issue, which I believe needs some work still.
guybedford commentedon Jul 11, 2025
With the reservation of
wasm-js:on WebAssembly import module names and the reservation of bothwasm:andwasm-js:on module export names, we could in theory use such a scheme to "encode" the import attribute information.For example, consider if we wanted to do:
in WebAssembly, we might write:
where the special export name
wasm-js:type/bytesis used to indicate that we are importing with a type attribute set to the string "bytes".Because these names are already reserved, this can be an addition at any point without being a shipping concern. Will continue to leave this open to track any interest / discussion or future interest.
[-]Integration with import assertions[/-][+]Integration with import attributes[/+]