This issue is inspired by:

• Support [target.'cfg(...)'.lib] sections rust-lang/cargo#12260

I will try to summarize somewhat.

Feature description

Currently, wasm-pack build passes arguments to cargo build, relying on that and Cargo.toml to be sufficient configuration. This can have problems when people want to build an application for e.g. both Web and Windows targets, as described by mcclure.

The proposed solution from a Cargo maintainer is this:

By removing the entire lib.crate-type from Cargo.toml your package should be back to default to compile bin for main.rs or rlib for lib.rs. If you have multiple Cargo targets, and you want to build only the library target, you could run something like

cargo rustc --lib --crate-type cdylib

This is unrealistic for users of wasm-pack, as they don't directly control how wasm-pack invokes cargo. Specifically, wasm-pack build means cargo build, with some argument passthrough, not "either cargo build or cargo rustc plus potentially some additional arguments". The proposed feature is to follow this suggestion internally in wasm-pack, adopting a design which deemphasizes lib.crate-type = ["cdylib", "rlib"] and relies on wasm-pack build setting --crate-type would allow this to happen more "automatically".

Tradeoffs

• This may impose a one-time upgrade cost on users (changes to Cargo.toml, etc.)
• This could raise the MSRV considerably, to around 1.63
  • Could be mitigated by version-checking, etc.
  • The current wasm-bindgen MSRV is 1.56: https://github.com/rustwasm/wasm-bindgen/blob/f569fddb62cdeb2bb9ba230fe59d3fba143cf92c/Cargo.toml#L15

Alternatives

Possible variants that still address this include adding a wasm-pack rustc command, so people can add --crate-type themselves, or adding more configuration options to wasm-pack build. But these would become odd to add to support what would likely be desired as the dominant wasm-pack build workflow, as then everyone must add configuration going forward. Still, maybe it's the best for maintainability of wasm-pack, even if it leaves the problem "unsolved".

Additional Notes

It's likely any preferred change, whether it is in wasm-pack or cargo, may prove disruptive (albeit in a "one-time" manner). I have spoken with T-cargo maintainers further on the Rust Zulip about the technical and social difficulties of educating programmers on updating for things like this. The team happens to have access to a very large megaphone (posts to the Rust blog), and is interested in making that available to help here, regardless of what technical solution is adopted. This would make it more likely Absolutely Everyone who spends any time in the Rust Programmer Anglosphere hears about it.