WebAssembly Support

[lastmjs]

It would be amazing to support WASM, so that C/C++/Rust and eventually many other languages could be automatically supported. Webpack is already working on this, and I've been working on it too here: https://github.com/lastmjs/zwitterion

I already have initial support for including basic C and C++ files, and WASM is now or will be ES module integratable.

It's possible and it would be awesome for this project to provide support.

[lastmjs]

You know, support for different file types besides just js should probably be discussed. This might be a major infrastructure change and decision that this library might want to make now. We're already talking about supporting at least ts files here: #3

[lastmjs]

And I am pleased to find out that this was already thought of, and parcel is file-type agnostic. Perfect. Then, let's support C/C++/Rust/wasm files. How do we do this?

[devongovett]

Yep totally want to support wasm. I did some initial experiments with this a while ago, and it should be pretty easy. I think WASM should definitely be supported in parcel core. Less sure about languages that compile to WASM like Rust since they usually depend on large toolchains, but perhaps it could work assuming installation instructions are documented well.

[albizures]

I can take a look at the implementation of rust, but yes, I agree with @devongovett, this shouldn't come out of the box, maybe a plugin?

[davidnagli]

@albizures I think you misread/miss-interpreted what Devon said. He said that it should be part of parcel core!

Parcel is trying to stay away from plugins, and trying to add all essential stuff directly to the core, to avoid the configuration mess of other tools like webpack.

[albizures]

@davidnagli 👍, I already made some progress but I have some problems...

I already upload it and I created the PR although it is not completed, maybe someone has an idea :)

PR: #312

[devongovett]

Progress: just merged #312 into the wasm branch!

I think we should go for a few milestones here.

1. First, let's get a WASMAsset merged that supports only precompiled .wasm files. This will be the base for other languages (e.g. rust) that compile to wasm.
2. Work on adding Rust support. Either autoinstall or warn if the proper toolchain isn't installed (rustc, wasm32-unknown-unknown, wasm-gc, etc.).
3. Add a WASMPackager that can combine multiple .wasm files together into a single one. Maybe we can use wasm-merge from binaryen to do that?

See also, my comment here about some details.

[albizures]

hey @devongovett, responding your points:

1. I created WASMAsset but I couldn't make it work with RustAsset without creating the wasm file alongside the rust file, so I ended up sending directly the wasm file to the dist folder using rustc. I don't think this is the best way to do this but I prefer this way rather than create the wasm file in the source code.
2. we could install wasm32-unknown-unknown and wasm-gc but for rustc I think it's better if we keep it as a warning
3. I'm not sure if it's a good idea make a wasm-merge at least for now

also, I already tried with --emit dep-info and it works great but now I'm creating a .d file alongside the source code. I read that with ReasonAsset is happening something similar this too, so I think this is something that we have to figure out how to manage this kind of temp files.

[devongovett]

Cool, I've been working on WASMAsset a bit myself, esp some changes that will allow us to preload external modules (that live in separate files) prior to executing the JS bundle. This will allow us to e.g. import {add} from './add.wasm' synchronously, without inlining into the JS. Instead, the JSPackager will add some code to the JS bundle to preload the WASM file prior to running the bundle.

This also involves some changes to allow registering custom bundle loaders for dynamic imports, e.g. extracting the existing support for JS and CSS, and adding a WASM file loader. So you'll be able to bundler.addBundleLoader('wasm', '/path/to/my/loader.js') for custom formats in plugins too.

I'm not sure if it's a good idea make a wasm-merge at least for now

Yeah, I realized that it isn't even possible to do what I wanted in the WASM format for now. A .wasm file consists of only a single module, so if you merge them you actually end up with a single module containing all of the exports rather than one file with multiple separate modules. Let's ignore that for now.

r.e. --emit dep-info, maybe we could ask the Rust people to make it possible to output this to stdout instead of a file...

[albizures]

esp some changes that will allow us to preload external modules (that live in separate files) prior to executing the JS bundle.

😲 this sounds really cool!

maybe we could ask the Rust people to make it possible to output this to stdout instead of a file...

yes, good idea! maybe even a json output 🤷‍♂️

[devongovett]

See here: #473

[devongovett]

Done in v1.5.0!