Tracing bindings through wasm

Has there been any discussion of whether to trace bindings through wasm modules?

If star exports find the same name twice, they consider it ambiguous and throw.

But if multiple paths lead to the same place it's not ambiguous. ESM traces bindings to detect this and load successfully.

The proposal currently drops tracing at wasm nodes. This might be surprising for devs. It means there's different load time behavior for a wasm module. If you had a dual build gadget (wasm with a JS fallback), intuitively it seems they should both work. But with reexports they don't. In a less capable environment, the JS version works. In a more capable environment, the wasm version throws an error.

export { widget } from './widget.mjs'

(func (export "widget") (import "./widget.mjs" "widget"))

Where a package reexports, this means a wasm build can't be used as a drop in replacement for the JS version.

[guybedford]

The concept of untyped forwarding is a difficult one to translate into Wasm in a way that is meaningful. Even with type enforcement, bindings would go through reinterpretation that effectively gives them a new identity.

In theory new constructs could be added to directly correspond to reexporting or wildcard reexporting, eg via a custom section in the Wasm binary or otherwise, but there would need to be use cases to justify anything like that, and none have yet come up.

So while exact equal parity at this level remains possible (these doors haven't been closed), it is not currently a goal given there isn't a strong use case justification.

[guybedford]

I ended up exploring better reexport bindings in #105 which only gain marginal benefits in very constructed cases with cycles. There is also strong resistance to deeper cyclical graph embedding, so we are sticking fully with the acyclic progressive linking model here.

Thanks for raising this though, it could have certainly been done.