Add wasm32v1-none Support

[bushrat011899]

Objective

uuid has support for no_std, and support for wasm32-unknown-unknown, but it currently doesn't have support for the alternative wasm32v1-none. Attempting to compile uuid with the v4 and js features on wasm32v1-none causes a compilation error due to getrandom.

Solution

Based on wasm32v1-none and wasm32-unknown-unknown documentation, and this compilation failure condition in getrandom, the configuration condition uuid should use for possibly-web Wasm is:

all(target_arch = "wasm32", any(target_os = "unknown", target_os = "none"))

That is, 32-bit Wasm with either an unknown OS (wasm32-unknown-unknown) or none (wasm32v1-none). The target_vendor condition is omitted based on the recommendations from the official Rust documentation linked above.

---

Notes

• I have also removed the implicit std features from js-sys and wasm-bindgen, and moved them into uuid/std. This may not be required, as wasm32-unknown-unknown still compiles without these std features enabled, but doing so reduces the chance of downstream issues.
• I've added a CI task "MVP Web" to ensure this particular target continues to compile going forward. Note that due to development dependency feature unification on older versions of Rust, you may need to use -Z avoid-dev-deps to test the target locally.

[KodrAus]

Thanks for working on this @bushrat011899! Just so I follow properly, we treat the wasm32v1-none target the same as wasm32-unknown-unknown with respect to our source of randomness? That is, if you enable the js feature of uuid you'll get our internal RNG support, but if you enable rng-rand or rng-getrandom you'll get theirs?

[bushrat011899]

Just so I follow properly, we treat the wasm32v1-none target the same as wasm32-unknown-unknown with respect to our source of randomness? That is, if you enable the js feature of uuid you'll get our internal RNG support, but if you enable rng-rand or rng-getrandom you'll get theirs?

Correct, the only difference between wasm32v1-none and wasm32-unknown-unknown is wasm32v1-none does not have a pre-built std implementation, and it explicitly uses the mvp target-cpu, which provides much better backwards compatibility with older web browsers. There's some further details in the documentation for the target. But the general plan is for wasm32-unknown-unknown to be the "bleeding edge" of Wasm, implementing all features and functionality in the spec that is "generally available", while the wasm32vX-none target(s) will strictly adhere to the X'th Web Assembly Core Spec for a more stable level of compatibility.

The no_std component here is a slightly more controversial choice, but is motivated by the fact that wasm32-unknown-unknown simply panics when certain elements from the std library are used, since they just have stub implementations. Making wasm32v1-none no_std avoids those footguns entirely, and is a better direction for Wasm on the web (IMO, at least until std can use the JS runtime and assume its existence somehow)

[KodrAus]

Thanks @bushrat011899! This looks great to me.