Support for wasm32-wasi target?

[iceiix]

Does wasm-pack support building for the new wasm32-wasi target instead of wasm32-unknown-unknown?

I have a project configured to use wasm-pack for wasm32-unknown-unknown, would like to switch to wasm32-wasi, wondering if I have to change the build tool, or if this is not supported and if there is a possibility it may in the future.

I tried wasm-pack build --target wasm32-wasi but this option specifies something else:

    -t, --target <target>        Sets the target environment. [possible values: browser, nodejs, web, no-modules]
                                 [default: browser]

Couldn't find any mention of "wasi" in this repository.

Background: https://github.com/CraneStation/wasmtime/blob/master/docs/WASI-intro.md

[fitzgen]

We don't support wasi yet.

It isn't totally clear what wasm-pack should do with wasi yet. (Not saying it is particularly difficult to figure out, we just haven't discussed it too much yet).

[RReverser]

Just allowing to somehow set target to WASI would be already good. Right now playing with porting some libraries to WASM via wasm-pack, but running into runtime panics due to unimplemented syscalls, which would be solved by passing WASI as a target.

[yurydelendik]

See also https://github.com/rust-lang/cargo/issues/7327

[RReverser]

@yurydelendik Looks like the linked issue has been resolved since.

[yurydelendik]

True. While underline tools are fixed, the wasm-pack code checks and operates only with 'wasm32-unknown-unknown' target.

[RReverser]

Yeah, and seems like at this point it would be a fairly simple fix to allow other targets.

[io12]

This would be a very useful feature.

[ctaggart]

I was hoping to use use clap command line parser in a Node.js app. clap heavily depends on os_str_bytes which does not support wasm32-unknown-unknown, but does support wasm32-wasi. clap compiles under wasm32-wasi. My app compiles under wasm32-wasi, but the rest of the stuff that wasm-pack does, I'm not sure how to handle.

Looking at https://nodejs.org/api/wasi.html, I probably need to upgrade my Node.js version and call wasi.start instead.

[Pauan]

I think this needs to be added to wasm-bindgen first before it can be added to wasm-pack.

[ctaggart]

I came across just now https://github.com/bytecodealliance/cargo-wasi and I'm not sure if I should use that directly instead for wasi projects in rust. Can some code be shared to add support to wasm-pack?

[RReverser]

@Pauan

I think this needs to be added to wasm-bindgen first before it can be added to wasm-pack.

Does wasm-bindgen differentiate or, indeed, even know, which target Wasm was built with? I think it should already work with wasm32-wasi built Wasm files like with the unknown ones.

IIUC the issue is only in wasm-pack because it passes the --target to cargo build, and that target is currently hardcoded to wasm32-unknown-unknown.

[Pauan]

@RReverser For WASI it is necessary to pass in the WASI functions, but wasm-bindgen doesn't do this, therefore wasm32-wasi won't work.

And there could be some other assumptions that wasm-bindgen makes about wasm32-unknown-unknown, but you'll need to talk to @alexcrichton about that.

[RReverser]

For WASI it is necessary to pass in the WASI functions, but wasm-bindgen doesn't do this, therefore wasm32-wasi won't work.

Ah yeah, that's a good point, these imports would have to be propagated via JS wrapper.

[Waridley]

Perhaps wasmer-js could be used to handle the WASI functions.

[Waridley]

It seems this may need supported in wasm-bindgen first since wasm-pack calls it to build and test projects. Idk if wasm-bindgen will want to add wasmer-js to polyfill the WASI syscalls or not, so if not, maybe that's something wasm-pack could do once wasm-bindgen supports building for wasm32-wasi.

[RReverser]

There is no need to commit to any specific implementation for WASI syscalls, the JS wrapper would simply need to propagate the imports and let Webpack config or whatever handle them by mapping to a real implementation.

[TheBlueMatt]

As of https://github.com/rust-lang/rust/pull/79998, in order to fix the use-case of linking C code (which passes structs by value) with Rust code, the wasm32-wasi target now has an ABI incompatibility with wam_bindgen (when passing structs by value). Thus, to make this happen someone would likely need to adopt https://github.com/rust-lang/rust-bindgen/pull/1952 and make the wasm_bindgen support the clang WASM ABI.

[proohit]

I've tried the examples of ssvm-wasi-helper documented at Access operating system resources from WebAssembly and it worked pretty well.

[Ciantic]

If you want to link WASM project against more advanced C libraries this is required.

WASI provides working LIBC for WASM. I haven't yet figured out how to build Rust library with C dependencies using wasm-pack.

[temeddix]

Perhaps wasmer-js could be used to handle the WASI functions.

I also believe we should use wasmer-js to bridge between WASI and JS APIs. It provides polyfill for time, strings, threads(with web workers), etc.

https://github.com/wasmerio/wasmer-js/issues/332#issuecomment-1779398973

[temeddix]

There seems to be an ongoing effort for wasm32-wasi target at wasm-bindgen repository, though it seems to have lost the momentum a little during the past few months. Please visit and leave your opinions so that this changes can become a reality :)

• https://github.com/rustwasm/wasm-bindgen/issues/3421
• https://github.com/rustwasm/wasm-bindgen/issues/3454