better wasm2js support
💡 Feature description
It would be great if we could use wasm-pack's build command to generate a js file that we'd get by calling wasm2js to (potentially) support browsers that don't have native wasm support. The output build files would contain an additional js file from wasm2js and potentially slightly different .js files for bootstrap logic.
I am not advocating for installing/requiring more tooling by default, but if a user wanted to opt into building additional assets it could handle install/setup for them like I assume the wasm-pack test commands do today.
I was able to get the wasm game of life example working with some slight adjustments to the already built wasm-pack files.
- requiring the wasm2js file instead of the
.wasmfile in the bootstrap js - changing the generated wasm2js file to not use exported
__wbindgen_throwmethod since it created import loading order error with js modules
If the output from wasm2js is not consistent across wasm projects (aka: it's broken in many situations or creates unmaintainable expectations for projects) then it's best to keep it entirely separate. However, if there's a chance it could just work it'd be helpful to be in supported in wasm-pack.
💻 Basic example
wasm-pack build --wasm2js
I don't really like this usage example, but I don't think the current
--targetflag is what we'd use to build an additional asset.
If having first-class support is not something that's desired in wasm-pack, then some small alterations to the assets built today could make it a one-line change to run a js version of a wasm asset by changing how we export/setup __wbindgen_throw.
Thanks for your time!
Implementation note: wasm2js introduction should wait until https://github.com/rustwasm/wasm-pack/pull/750 merged, as it'll be easier.
Support of asm.js from wasm-pack will be awesome. I really miss simple solution of producing fallback that will be compatible with non-wasm browsers.
Would also like to have an asm.js fallback support in wasm-pack, this would make using/integrating wasm modules much more feasible in real-world projects
Compatibility for non-wasm browsers would be a life-safer now that V8 and thus Chrome 91 broke WASM support, for now breaking the whole Rust-on-the-web-client ecosystem.
Btw, is there any known work-around the lack of wasm2js support? Like a Webpack plugin that can execute wasm2js through a shell script just after the execution of wasm-pack through WasmPackPlugin? Maybe that is a question for wasm-pack-plugin's issue tracker though...
Btw, is there any known work-around the lack of
wasm2jssupport? Like aWebpackplugin that can executewasm2jsthrough a shell script just after the execution ofwasm-packthroughWasmPackPlugin?
No but it looks not so difficult to do. There is a wasm2js CLI included in binaryen NPM package. I guess it's compiled to wasm.
One option is to add an option to WasmPackPlugin to execute that after wasm-pack and change the import from *.wasm to *.js.
Other option is to clone WasmPackPlugin, change what command execute and plugin's name and add that new plugin just after WasmPackPlugin.