Disable support for wasm32-wasi

[gbj]

At present, wasm-bindgen inserts bindings on any target that has a) the target architecture wasm32 and b) not the target OS emscripten. This means that wasm-bindgen does insert bindings for the target wasm32-wasi, which causes wasm32-wasi binaries to behavior differently from binaries on all other targets. See further discussion here bytecodealliance/wasmtime#5557

This PR simply updates the "is this Emscripten?" check to add an "is this WASI?" check, leading to a panic if a wasm-bindgen function is called but not preventing WASI runtimes like wasmtime from loading and running the binary.

I've tested this against the very example I gave in my issue in the wasmtime repo (linked above), and it resolved that issue, allowing you to load and run a binary with wasm-bindgen dependencies (like web-sys) as long as you don't actually run them — as is the behavior on other native targets.

[bajtos]

AFAIK, there are browser-like JS environments that support WASI too - Node.js and Deno.

Ideally, we should be able to compile Rust code for the wasm32-wasi target, while using wasm-bindgen for interfacing with JS APIs.

Isn't this pull request breaking support for such scenario?

[gbj]

Oh, interesting point. I’m not familiar enough with Node or Deno WASI support — is there any distinction in compile target between “WASI within JS environment” and “WASI without JS environment”? If not, that’s… unfortunate.

[bajtos]

Oh, interesting point. I’m not familiar enough with Node or Deno WASI support — is there any distinction in compile target between “WASI within JS environment” and “WASI without JS environment”? If not, that’s… unfortunate.

I am afraid I am not an expert in this area either :(

I think there are very few people that are running WASI in Node.js & Deno context, so maybe it's not that bad if wasm-bindgen stops working for wasm32-wasi after your change.

I have two suggestions if I may:

1. Could you please change the title of your pull request to explain what is the effect of your change on the users, instead of describing the implementation details? For example: "Don't inject bindings when targeting wasm32-wasi" or "Disable support for wasm32-wasi".

2. I think this should be treated as a breaking change and clearly described in the release notes.

[gbj]

I think this should probably either be behind a feature, or is the wrong approach, due to the possible Node/Deno compatibility issues.

[daxpedda]

I honestly don't know much about WASI, but it seems a bit counterintuitive to me to use WASI with Node.js or Deno if you intend to access JS, because WASI wouldn't offer anything in that case.
I think the intention of WASI support on these platforms is to support C/C++ that don't have a wasm-bindgen equivalent, or Rust for that matter that doesn't need JS access but now has an easy way to write cross-platform code.

If you want to use parts of the WASI API nevertheless, you can just import that through JS.

But yeah, input from somebody actually knowledgeable about this would be appreciated.

[daxpedda]

I'm happy to get this merged @gbj, got notified from #3421 (comment).

Would you mind rebasing and adding a comment to the changelog?

[daxpedda]

Thanks!