Target architecture wasm32 should not assume a Javascript environment

[lpahlavi]

Problem

When the solana-system-interface crate is compiled to wasm32, the dependency wasm-bindgen is included.
For example here:

[target.'cfg(target_arch = "wasm32")'.dependencies]
js-sys = "0.3.72"
wasm-bindgen = "0.2"

The wasm-bindgen crate only makes sense if the compiled wasm is to be used in a Javascript environment (typically a browser); however, there are many other use cases for compiling to wasm and running the compiled wasm outside a web environment. Currently this fails due to the presence of wasm-bindgen.

Proposal

Only pull the wasm-bindgen crate when a feature flag indicating a Javascript environment is present.

See #48 and a similar issue in the solana-sdk repository here.

[buffalojoec]

Hey @lpahlavi sorry for the delay here. The linked article also mentions that non-browser environments could be JavaScript, so we don't want a feature for non-JS, but rather a feature for non-browser.

In your linked PR, I'm wondering if the js feature name makes sense here. Why not browser or bindgen?

Also, what does the presence of wasm-bindgen do that causes the failure? I'm not super familiar with wasm-bindgen myself, but I didn't want to leave you hanging here!

[lpahlavi]

Hi @buffalojoec, thanks a lot for having a look at this! No worries about the delay, I was myself on holidays for the last 2 weeks hence the delay on my side.

The linked article also mentions that non-browser environments could be JavaScript, so we don't want a feature for non-JS, but rather a feature for non-browser.

In your linked PR, I'm wondering if the js feature name makes sense here. Why not browser or bindgen?

I don't have a particularly strong opinion about this, and could be convinced to change it, but I used js mostly because:

1. The purpose of wasm-bindgen is to offer an interface between WASM and the JavaScript engine.
2. Other Rust crates have used similar names for the same feature flag (see @joncinque's comprehensive comment here), although there is some variation there.
3. I would try to be consistent with the corresponding feature in the anza-xyz/solana-sdk repository. One could argue that the feature flag name should be changed there as well though.

Also, what does the presence of wasm-bindgen do that causes the failure? I'm not super familiar with wasm-bindgen myself, but I didn't want to leave you hanging here!

It seems to me that the problem is that WASM code where wasm-bindgen is used tries to import some functionality that is not available in non-browser environments. This is problematic for example, for canister smart contracts on the Internet Computer, see this forum post for more details (including some error messages when trying to use wasm-bindgen in a non-browser environment).