Latest WebAssembly ESM Integration rebase

[guybedford]

WebAssembly ESM Integration including Source Phase Imports

This represents the latest rebase of the ESM Integration spec, replacing the original PR in #4372. Major changes since then include source phase imports support and instantiation being updated to be synchronous.

• At least two implementers are interested (and none opposed):
  • Chromium (with V8 source phase design doc)
  • Node.js
  • Deno
  • Previously WebKit, pending impl refresh
• Tests are written and can be reviewed and commented upon at:
  • Initial ESM Integration: WebKit export of https://bugs.webkit.org/show_bug.cgi?id=236268 web-platform-tests/wpt#32862
  • Source phase support: [wasm] Source Phase Imports for ESM Integration web-platform-tests/wpt#42467, [wasm] esm integration test updates web-platform-tests/wpt#45401
  • Tentative -> Non-tentative PR: [wasm] Move ESM Integration out of tentative web-platform-tests/wpt#46556
• Implementation bugs are filed:
  • Chromium: https://issues.chromium.org/issues/40244733, with source phase support tracked in https://issues.chromium.org/issues/42204365
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1899832
  • WebKit: https://bugs.webkit.org/show_bug.cgi?id=274908
  • Deno (only for timers, structured clone, base64 utils, channel messaging, module resolution, web workers, and web storage): Support importing wasm modules  denoland/deno#2552
  • Node.js (only for timers, structured clone, base64 utils, channel messaging, and module resolution): Tracking issue: latest ESM Integration support nodejs/node#53178
• MDN issue is filed: Add support for WebAssembly ESM Integration mdn/mdn#549
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

/acknowledgements.html ( diff )
/indices.html ( diff )
/infrastructure.html ( diff )
/references.html ( diff )
/webappapis.html ( diff )

[guybedford]

For the question of why Wasm and JS are treated as equal capabilities in the module system, the reasoning here is that unlike other resource imports which are implemented as synthetic modules, Wasm modules are implemented as full cyclic module records that can in turn import any other JS modules. Therefore while Wasm itself is usually a securely sandboxed language, as soon as you have arbitrary imports to JS, you have equal capability since any Wasm module imported this way can import and therefore execute arbitrary JS in turn.

[guybedford]

Thanks for the review, I've addressed the changes in f816de8.

[annevk]

@nicolo-ribaudo could you have a look at this please? Looks editorially okay to me.

[nicolo-ribaudo]

✔️

[guybedford]

I've integrated the latest changes here so we should be good to go.

Just let me know if I can do anything to help get the participation check passing.

[domenic]

Just let me know if I can do anything to help get the participation check passing.

It looks like you signed up as an individual at some point, but you work for Fastly, which has signed up as an entity. However, Fastly has only signed up to contribute to Fetch.

So this is a bit complicated. The ideal steps needed are:

• @fastlyneal needs to send a PR to update this part of entities.json to include the HTML workstream. (He might also want to remove mnot as a GitHub contact there, since mnot appears to no longer work at Fastly...)
• You can send a PR to remove yoursself from https://github.com/whatwg/participant-data/blob/main/individuals.json
• You need to join, or make public your membership in, the Fastly GitHub organization.

[guybedford]

The participation check is now passing. @domenic thanks for the clear help with this.

[domenic]

This looks ready to merge to me, but I'm not 100% sure that we have multiple browsers interested in implementing exactly this shape of the proposal. We have zero browsers passing the tests, for example: https://wpt.fyi/results/wasm/webapi/esm-integration?label=experimental&label=master&aligned

[annevk]

Although the WebKit team at Apple was initially somewhat skeptical about bundling JS and Wasm as a single destination, we're okay with that now under the expectation that the privileges and capabilities of JS and Wasm won't diverge.

Who can speak for Chromium, maybe @syg?

And Gecko would be @codehag or @mgaudet perhaps?

[codehag]

This looks ok from our side.

[guybedford]

@ajklein may also be able to speak to the current progress on the V8 implementation here.