🐛 Bug description

wasm-pack makes the assumption that the final binary for the build command will always be target/wasm32-unknown-unknown/{debug|release}/whatever.wasm regardless of the build options passed to Cargo, some of them change the result of the final path but still emit a binary since the invalid path also gets a different binary. The case I've been running into is when passing --tests to Cargo a file with tests compiled into the binary will be emitted to target/wasm32-unknown-unknown/debug/deps/$NAME-$HASH.wasm and a binary without tests compiled in will be emitted to target/wasm32-unknown-unknown/debug/$name.wasm.

🤔 Expected Behavior

wasm-pack should run wasm-bindgen on the final binary specified by Cargo by parsing Cargo's message format. I'm willing to author a PR fixing this since this issue is blocking for me.

👟 Steps to reproduce

These following command will build give you the path Cargo emitted the correct binary to, but wasm-pack won't operate on:

$ git clone [email protected]:zebp/wasm-pack-test-repro.git
$ cd wasm-pack-test-repro
# Sometimes this flakes and returns "null", not sure why.
$ wasm-pack build --dev -- --tests --message-format=json-diagnostic-rendered-ansi | tail -2 | head -1 | jq --raw-output .executable
# Has the expected function names conditionally compiled with #[cfg(test)]
$ strings $THE_PATH_FROM_LAST_STEP | grep a_very_unique_name_to_grep
# Doesn't have the expected functions since cargo didn't emit a binary with tests enabled to location wasm-pack used
$ strings ./pkg/wasm_pack_test_repro_bg.wasm | grep a_very_unique_name_to_grep 

Note, this is flaky for some reason specifically when using wasm-pack. If you use the same arguments to Cargo directly it always acts as expected.

🌍 Your environment

Include the relevant details of your environment.
wasm-pack version: 0.13.0
rustc version: 1.79.0 (129f3b996 2024-06-10)