What is the expected behavior?
Ideally it would be somehow possible, when importing a wasm file as an ESM, to get a hold of the WebAssembly.Module object. Currently, however, I believe that the instantiation of the WebAssembly.Instance is hidden in weback (that's good!) but it ends up burying the instance of WebAssembly.Module and WebAssembly.Instance, not allowing JS code to grab ahold of it and manipulate it.
What is motivation or use case for adding/changing the behavior?
The main motivation for this use case is the upcoming threads proposal in WebAssembly. With threads one visions for idiomatic usage is to post a WebAssembly.Module to a set of worker threads (along with a SharedArrayBuffer). All worker threads would then use the exact same compiled code and shared memory, allowing for reduced resource usage and faster instantiation as the module no longer needs to be fetched and compiled once per thread.
To that end, the moviation here is implementing a method for Webpack to be used while also enabling this method of multithreaded wasm, posting a WebAssembly.Module instance to worker threads.
How should this be implemented in your opinion?
There's unfortunately no great way to implement this mapping to the ESM spec for wasm. I've opened an issue on the wasm ESM integration repository for this feature, but there's not consensus yet on what to do. The idea, though, is that just like how an wasm "ESM" can export its own memory it could also export its own instance/module (somehow).
In any case in the meantime I'm hoping that we could polyfill WebAssembly/esm-integration#14 somehow or otherwise enable it. I'd personally be ok with "magic names" that automatically and synthetically get added to a wasm ESM export list (like __webpack_webassembly_module).
Are you willing to work on this yourself?
I can try! I'd need some assistance though in navigating around.
cc @xtuc, you likely have thoughts on this!
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4