esm: WebAssembly.namespaceInstance

[guybedford]

This implements the WebAssembly.namespaceInstance function as defined in https://webassembly.github.io/esm-integration/js-api/index.html#dom-webassembly-namespaceinstance-namespace.

This function can be used to obtain the underlying WebAssembly.Instance object for a WebAssembly module record module namespace.

Ideally this would be implemented in V8, but they are not currently implementing the instance phase, so this is left for us to patch here.

Example:

import * as mod from './mod.wasm';
WebAssembly.namespaceInstance(mod) instanceof WebAssembly.Instance // true

Internally this then shares the existing weakmap lookup that was already previously implemented.

[nodejs-github-bot]

Review requested:

• @nodejs/loaders
• @nodejs/startup
• @nodejs/web-standards

[guybedford]

@nodejs/loaders

[codecov]

Codecov Report

Attention: Patch coverage is 87.50000% with 3 lines in your changes missing coverage. Please review.

Project coverage is 90.05%. Comparing base (e3e739d) to head (ab658c4).
Report is 3 commits behind head on main.

Files with missing lines	Patch %	Lines
lib/internal/wasm_web_api.js	83.33%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #59024      +/-   ##
==========================================
- Coverage   90.07%   90.05%   -0.02%     
==========================================
  Files         645      645              
  Lines      189128   189145      +17     
  Branches    37091    37095       +4     
==========================================
- Hits       170355   170342      -13     
- Misses      11459    11513      +54     
+ Partials     7314     7290      -24     

Files with missing lines	Coverage Δ
lib/internal/errors.js	97.50% <100.00%> (+<0.01%)	⬆️
lib/internal/modules/esm/translators.js	92.28% <100.00%> (ø)
lib/internal/wasm_web_api.js	96.42% <83.33%> (-3.58%)	⬇️

... and 28 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[legendecas]

The WebAssembly API is implemented in V8.

I think this should be categorized like a JavaScript built-in API that should be implemented in V8, instead of polyfilling in Node.js.

Does V8 oppose to the change?

[guybedford]

@legendecas there are two ESM Integration phases - instance and source phase. V8 has an implementation of the source phase but not an implementation of the instance phase.

Ideally, V8 would implement the instance phase with a WebAssembly Module Record with a [[Instance]] slot pointing to the WebAssembly.Instance allowing for the implementation of a WebAssembly.namespaceInstance. This would also allow live mutable global bindings for WebAssembly module record exports as well.

But without that, we need to maintain our own side table in Node.js for the Wasm Module <=> Wasm Instance link which is the weak map here used to create WebAssembly.namespaceInstance.

When we unflag this implementation soon, we thus have two options:

1. Wait for V8 to implement Wasm module instances with a WebAssembly Module Record implementation, not shipping WebAssembly.namespaceInstance in the mean time.
2. Ship our Wasm module instance implementation with the best WPT compat that we can.

I don't see any reason not to do (2), but if you have strong arguments for (1) I'm happy to reconsider landing this. It would just help to hear a single good reason why not shipping a feature would be truly beneficial in this case.

I have a preference to shipping as much correctness as possible even though we can't support live bindings we get everything else, but I'm also open to alternatives here.

[legendecas]

We have layers of implementations and their scopes. Node.js is definitely capable of implementing any APIs that are useful. But for a standardized API, which falls in V8's scope of implementation, I think we should pursue implementing it in V8 first.

I'm curious about the reason why we should circumvent V8 to implement this API in particular. If V8 or Chromium is not willing to implement it, I'm more worried about the standardization process. If it just needs some volunteers to take the task, I think implementing it in Node.js is just doubling the effort/waste, given that it will eventually be superseded by V8's work.

[guybedford]

I'm curious about the reason why we should circumvent V8 to implement this API in particular.

It is purely a question of resources.

If it just needs some volunteers to take the task, I think implementing it in Node.js is just doubling the effort/waste, given that it will eventually be superseded by V8's work.

Are you interested or do you know anyone interested in working on WebAssembly Module Record in V8 here? If so, let's definitely continue this discussion further.

[guybedford]

I discussed this some more with @legendecas offline, and he raised the argument that came from experience with Symbol.dispose where avoiding conflicting implementation approaches should be avoided where possible in case of implementation conflicts, and I can certainly empathize with that argument here in that any future V8 implementation could conflict with this approach.

While in theory it is a slightly less compatible implementation, I'm happy to rather close this and reconsider it instead at a later point if a real use case comes up strongly with urgency.

Otherwise, in the mean time, we can still ship the Wasm ESM Integration as experimental without requiring this feature.

Closing for now, further feedback here is welcome.