`target` dir and compiled wasm is not found when using a workspace

[colemickens]

https://github.com/atom/xray uses a workspace.

As I'm trying to move it to wasm-pack, I'm getting stuck due to it looking for target/ next to the local Cargo.toml, instead of the top-level workspace target/ dir next to the top-level Cargo.toml/Cargo.lock.

xray/
 | - target/wasm32-unknown-unknown/...
 | - xray_wasm/Cargo.toml # the project using wasm-pack/wasm-bindget
 | - Cargo.toml # the workspace toml

But it only looks for xray_wasm/target/....

[colemickens]

Looks like the problem is here: https://github.com/rustwasm/wasm-pack/blob/master/src/bindgen.rs#L46

There is a subcommand for cargo, cargo metadata, but it's not built-in.

I'm wondering if it's possible to include the functionality of cargo metadata in wasm-pack to discover the $.target_directory property of the metadata that points at where artifacts are.

[mgattozzi]

Hey @colemickens thanks for taking the time to track this down! I think we've been writing the code with the assumption "This is not a workspaced repo" since we've been thinking of "this is one thing being uploaded to npm". I think this is a possible workflow, but I'll need to double check.

[ashleygwilliams]

workspace support is def on the roadmap, i'm just not sure where. can talk about it at the meeting this week! i would of course accept a PR for this!

[colemickens]

Thanks for the replies! The only thing I'd thought of was a small bit to sniff out if the current directory contained "Cargo.lock", and if not checking in the parent directory/directories. (For anyone else reading, I'm not actively looking into using wasm-pack right now, so I'm unlikely to author a patch.)

[rbuckland]

My use case is a overarching library that encompasses

• wasm published version
• rust native lib
• command line binary

and as a result, it's split up into workspace subdirs. https://github.com/inosion/madato/tree/wasm_separate

@ashleygwilliams How did the meeting go regarding a direction ?