feat: support wasm32-unknown-emscripten target

[guybedford]

This adds support for the wasm32-unknown-emscripten target alongside the existing wasm32-unknown-unknown flow. The emscripten target makes std-library APIs that aren't available under wasm32-unknown-unknown usable from wasm-pack-built crates: SystemTime, std::env, std::fs (via MEMFS), HashMap default random state, rand::random via getentropy, and POSIX-style I/O.

The build runs four discrete phases, each a self-contained tool invocation:

1. cargo build → librustworker.a (staticlib)
2. emcc link → bare .wasm (no JS, just wasm-ld)
3. wasm-bindgen → rewritten .wasm + library_bindgen.js
4. emcc --post-link → final .mjs ESM + .wasm

Included:

• target detection via --target arg, CARGO_BUILD_TARGET env var, and a workspace-aware .cargo/config.toml walk (matches cargo's own precedence)
• emcc auto-discovery via PATH / $EMSDK / ~/emsdk plus a soft version check (warns below 3.1.60 — the floor for -sSOURCE_PHASE_IMPORTS)
• per---target mapping to coherent emcc settings (bundler / web / module / nodejs / deno; rejects no-modules)
• source-phase imports (import source wasmModule from './foo.wasm') for --target module
• -O2 optimization (capped to avoid wasm-opt's export minifier renaming the wasm-bindgen-required exports)
• crate-type diagnostics: emscripten requires staticlib, default targets require cdylib; both surface clear errors when misconfigured instead of cryptic downstream failures
• wasm-pack new --emscripten template alongside the existing one
• docs at docs/src/emscripten-target.md
• 8 integration tests + 5 unit tests

Three supporting changes came along while building this and apply to the default flow too:

• WASM_BINDGEN_BIN env var support, for pointing wasm-pack at a locally-built wasm-bindgen during iteration
• wasm-opt invocation now passes the full Wasm 3.0 feature flag set so it handles any standard wasm feature instead of erroring on exception-handling, bulk-memory, etc.
• the wasm-pack publish interactive prompt now offers deno and module alongside the older targets

wasm-pack test is rejected for the emscripten target with a clear message. wasm-bindgen-test's runner isn't wired for emscripten and the integration is non-trivial.

The integration-test fixture depends on wasm-bindgen = "=0.2.122" (which includes the emscripten output-mode fixes) directly from crates.io. wasm-pack reads the fixture's lockfile and downloads the matching CLI on its own; no [patch.crates-io] block or sibling-checkout plumbing is needed. The wasm-pack new --emscripten template also pins wasm-bindgen = "0.2.122" as its floor so scaffolded projects pick up the fixes by default.

One remaining upstream item, with the corresponding workaround commented with a TODO link and removable once it lands:

• emscripten — acorn-import-phases plugin so emcc's JS optimizer can parse source-phase imports. Has landed on emscripten main, awaiting a tagged release. Today --target module builds run unoptimized (--no-opt); once the next emscripten release ships they can use -O2 like everything else.
• emscripten — TSD_SKIP_EXPORTS setting so --emit-tsd doesn't assert on wasm-bindgen-style multi-value-return exports. The .d.ts merge plumbing in step_emcc_post_link is in place but parked behind emscripten_dts: Option<PathBuf> = None; until that lands.

Tracking issue for panic=unwind on emscripten via wasm-bindgen linked from the docs; the template ships with panic=abort until that combination is supported.

Pre-merge review

A self-review pass surfaced and addressed (commit 6282abf):

• Windows correctness — emcc is invoked via the full path resolved by which::which("emcc") rather than the bare string. Rust's process spawner doesn't honour PATHEXT for bare names, so Command::new("emcc") would have failed to find emcc.bat. Stashed on Build in step_check_for_emcc and threaded through emcc_link/emcc_post_link. Works on Windows since Rust 1.77's CVE-2024-24576 fix added explicit .bat handling for full paths.
• Test PATH separator — prepend_path helper uses std::env::join_paths instead of a hardcoded ":".
• Node driver path safety — make_node_driver JSON-encodes the .mjs URL so Windows-style backslash paths can't break out of the JS string.
• Stale comment — corrected docs that referenced a since-removed EmscriptenRuntime interface in the .d.ts decoration.
• Match arm consolidation — Target::Bundler | Web | Deno collapsed into a single arm; they emit identical post-link settings.
• Cargo.lock churn — restored to a clean minimal diff (only +4 lines for the dirs crate's chain).

Testing:

source emsdk_env.sh
cargo test --test all emscripten::

The 8 integration tests exercise each --target variant end-to-end (each one drives a Node-based smoke test through the produced .mjs that covers string passing, closures, typed arrays, Result, classes, and Rust→JS imports), plus rejection cases for invalid combinations. 5 unit tests cover the version parser and the workspace-aware .cargo/config.toml walk.

Ready to merge once CI is green; will land after the next emscripten tagged release so --target module builds can drop --no-opt.

[walkingeyerobot]

This looks awesome, thanks!

I think this is awesome overall, but I did want to ask: do we need to have emcc invoke wasm-ld? What are the pros and cons vs just invoking wasm-ld directly here? I think this is a pretty minor point and you could reasonably ignore this question.

[walkingeyerobot]

a linked issue / PR here would be helpful. then once the upstream fix is in, readers could see the PR was merged and would know this is no longer the case.

[guybedford]

The upstream fix has now landed for this one, I will merge it in here and reenable after the next emscripten release.