Usage of compiler --cfg flag to select a feature is an egregious anti-pattern in the Rust ecosystem

[tgrushka]

Suddenly, my WASM build starts crashing when I'm trying to just do my due diligence and keep up my dependencies.

The reasons I moved to Rust include:

• actually stable and reliable dependency system
• friendly compile errors
• not having to use esoteric flags and configs just to make dependencies happy

This crate, though not even a direct dependency in my project, violates all of these principles:

• A build that was working suddently fails, and the reason is apparently "security" (which, by definition, is mutually exclusive with good user experience, right?) -- rather than just having me naturally add a single feature flag via deprecation warnings, the crate puts the burden on me to figure out its esoteric error message, which brings me to the second point:
• The error message includes the ever-so-helpful instruction: "Note that enabling the ``wasm_js`` feature flag alone is insufficient." and then falls totally short of explaining what else is needed... 🤦 nice.
• I then discover to my dismay that I have to:
  • add this crate as a direct dependency to my project, yet another to maintain, AND
  • Play around with TOML to figure out how to add a strange config flag with an escaped quoted key-value pair, just to make this crate happy -- not very Rusty:

rustflags = ["--cfg=getrandom_backend=\"wasm_js\""]

The use of a --cfg compiler argument to select a feature is a design flaw and an anti-pattern, not a necessity! It shouldn't be needed unless the feature is unstable. The feature alone should select the backend. If it conflicts, remove the other backends from default features. I've never seen other crates that require a --cfg flag to enable features except web-sys with its --cfg=web_sys_unstable_apis, but that is understandable, because I am using unstable Web APIs, and those are beyond the control of the Rust community entirely. They have an excuse. A crate that deals with random number generation really doesn't have this excuse, because it's not using unstable Web APIs, or shouldn't be!

In my cargo tree, this crate is a dependency of:

• tempfile v3.23.0
• gloo-history v0.2.2
• nanorand v0.7.0
• rand_core v0.6.4
  • rand v0.8.5

Seems there are a lot of intermediate crates that depend on this one, and that is just going to cause a ton of pain among downstream developers that have to be burdened with figuring out how to handle this.

The Rust ecosystem is getting sloppy! This will only serve to frustrate developers when they get into more than academic projects. We are trying to get more people and companies, not fewer, to adopt Rust because, "it just works." It's safe, and safety is a concern, but that's why there are feature flags. Fine, make the backend selection explicit by requiring a feature flag. But a --cfg requirement? For heaven's sake, if one adds the feature flag, wasm_js, why on earth is a --cfg with essentially the exact same feature flag required? Is it unstable or something? If it's unstable, why are stable downstream dependencies suddenly having this compile error? Why was this not introduced in a proper semantic version update, or an unstable incremental or pre-release version? It just went and broke intermediate dependencies, and this is exactly what I had hoped to avoid by moving to Rust.

Sorry for the rant, but this is the level of frustration that I've had to deal with to stop what I'm working on and fix this bug that had nothing to do with my project.

error: The wasm32-unknown-unknown targets are not supported by default; you may need to enable the "wasm_js" configuration flag. Note that enabling the `wasm_js` feature flag alone is insufficient. For more information see: https://docs.rs/getrandom/0.3.3/#webassembly-support
   --> /Users/tom/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/getrandom-0.3.3/src/backends.rs:168:9
    |
168 | / ...   compile_error!(concat!(
169 | | ...       "The wasm32-unknown-unknown targets are not supported by ...
170 | | ...       you may need to enable the \"wasm_js\" configuration flag...
171 | | ...       that enabling the `wasm_js` feature flag alone is insuffi...
172 | | ...       For more information see: \
173 | | ...       https://docs.rs/getrandom/", env!("CARGO_PKG_VERSION"), "...
174 | | ...   ));
    | |________^

[josephlr]

@tgrushka I would ask you to keep any feature requests or bug reports respectful. The people maintaining this crate are volunteers. We know that the experience when using wasm32-unknown-unknown is not ideal, but this is mostly because we cannot assume that JavaScript exists on that target.

I also think the issues you are facing are caused by using an old version of this crate. In v0.3.4, we fixed this exact issue. Now you only need to enable the Cargo feature flag wasm_js to use the JavaScript backend on wasm32-unknown-unknown. Selecting other non-standard backends still requires using --cfg=getrandom_backend.

As for your complaint about the error message, the full message is:

error: The wasm32-unknown-unknown targets are not supported by default; you may need to enable the "wasm_js" configuration flag. Note that enabling the wasm_js feature flag alone is insufficient. For more information see: https://docs.rs/getrandom/0.3.3/#webassembly-support

And that section of the docs that is linked should explain everything you need to do. If you have suggestions for improvements to the error message, pull requests are welcome.

Why was this not introduced in a proper semantic version update, or an unstable incremental or pre-release version? It just went and broke intermediate dependencies, and this is exactly what I had hoped to avoid by moving to Rust.

This functionality of selecting the backend via --cfg=getrandom_backend was added in v0.3 of this crate, a semver braking change.

[dhardy]

The root cause of this issue is that wasm32-unknown-unknown is an underdefined target that says nothing about what run-time environment is available while getrandom provides functionality that should be in the standard Rust library. We are forced to hack around this mess.

Worse, wasm32-unknown-unknown is now quite widely used. It should eventually be deprecated or at least made mostly obsolete (replaced by WASI).

In the mean-time, about the only other thing we can do is to remind users that WASM (in any form) is not yet a tier 1 Rust target.

There is nothing actionable here therefore I am closing the issue.