Guy Bedford

On a somewhat (or maybe not) related note discussing the most flexible JS API for Wasm imports, I jestingly suggested to @kripken: ```js import module from './file.wasm'; const mod =...

> @guybedford Hah, yeah, I've imagined that being useful too to handle more complicated scenarios without falling back to instantiateStreaming(fetch()). Maybe this could be achieved via a separate import attribute...

Thinking about the above ESM integration idea further, of course if any imports were attached to such a partial Wasm import it's no longer transferrable to workers so it isn't...

It is great to see progress here. Are there any examples of how this would be used in the ESM integration for Wasm?

I understand the need for wrapping, at least while WebAssembly.Module type Wasm imports are not yet possible (and hopefully they will be in due course). More specifically though, I was...

> Feedback I had received was that there was a desire to not change ESM integration either Can you ellaborate on where this feedback is coming from? There is a...

I misread @Jack-Works's comment, have adjusted my comment above. Thanks @RossTate for the clarifications, yes I'm suggesting exploring the possibility matching these import and export suspension contexts via metadata in...

Just came across this one myself, would have been stuck had I not been able to find this issue in the search - never would have thought it was a...

Definitely agreed, it would still be amazing to see this. _Module splitting_ could possibly be done by some kind of algorithm that attempts to find the disjoint binding sets within...

Did you try using the renderChunk hook here? I believe it should be possible by treating the service worker file as a module in input (even if it has no...