Remove all uses of getrandom_backend = "wasm_js"

[newpavlov]

Enabling the wasm_js crate feature is sufficient.

[dhardy]

Removal of getrandom_backend="wasm_js" is a breaking change; it makes sense to merge this before 0.4 (I assume this is your intention).

[dhardy]

or gated on a crate feature

I see no hard reason not to have a "forwarding" feature flag (e.g. wasm_js = ["getrandom/wasm_js"]).

I know you don't like this pattern, but I don't think directing users like this will work particularly well.

I suggest we keep our advice direct and minimally opinionated:

We recommend against enabling this feature in libraries (except for tests) since it is known to break some non-Web WASM builds and further since the usage of wasm-bindgen causes significant bloat to Cargo.lock (on all targets).

[josephlr]

I think having a default guidance against forwarding crate features is a reasonable. It's mostly that you run into semver and stability issues when trying to forward the features of other crates. It's possible to do, but really only works if:

• you pay extra close attention to the issues
• you work closely between the forwarding crate and getrandom (like rand does).

[josephlr]

Overall this seems reasonable if it's part of a breaking change for 0.4 (and the changes to tests/documentation might be good to also have in 0.3).

It might be worth mentioning (somewhere) that we used to allow --cfg getrandom_backend="wasm_js" (but don't anymore for 0.4)

[dhardy]

Then I approve.

[newpavlov]

It might be worth mentioning (somewhere) that we used to allow --cfg getrandom_backend="wasm_js"

This change does not "forbid" --cfg getrandom_backend="wasm_js" in any way. It's simply gets ignored and the only visible consequence is lack of the compilation error which warns users to enable the wasm_js feature (instead users will get a different compilation error).

So, arguably, this change is not a breaking one and arguably we should've done it as part of the v0.3.4 release.