search

WebAssembly / esm-integration

ECMAScript module integration
https://webassembly.github.io/esm-integration/js-api/index.html#esm-integration
Other
372 stars 32 forks source link

Tracing bindings through wasm #87

Open bojavou opened 2 months ago

bojavou commented 2 months ago

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.

collide

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

disambiguate-value

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.

gadget

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 commented 2 months ago

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.