Repository navigation
Allow path expansion/modification for the deps directory in generate! #1675
Description
Feature
allow wit_bindgen::generate! (and wasmtime::bindgen!) to link a dependency tree that is not a sibling path to the root WIT package to be generated:
bindgen!({
world: "foo",
path: "other/path/to/wit",
deps: "path/to/foo/dir/deps", // behaves as "other/path/to/wit/dir"
// ...
});Benefit
This would allow aggregation of dependency trees for multiple packages that share different directories
Implementation
Likely u directory association inside of bindgen! wasmtime::Config
Alternatives
Symlinking, this is not supported on windows 😢
Activity
depsdirectory in bindgen wasmtime#14026 as a duplicate of this issuenonik0 commentedon Jul 30, 2026
Also additionally allowing the provided
pathand/or potentiallydepspaths to expand to allow the use of env vars to encapsulate the "path expansion" part of this issue. This would make referencing shared deps between components more robust through the use of env vars in the provided paths, rather than relying on relative paths that could break or absolute paths that are not portable.celarye commentedon Sep 21, 2026
My first instinct was for a feature like this as well, but what if you have multiple packages across different directories where:
I can think of two ways to solve this use case:
Either way, I am willing to start with implementing mkatychev's feature request for now. Both for wit-bindgen and wasmtime's
bindgen!.celarye commentedon Sep 22, 2026
I've managed to get something working, it's used as:
I made it so the deps path is not relative to the WIT path.
I had to go and update the
wit-parsercrate (hosted in the wasm-tools repo) for this as thedepssubdirectory was hardcoded there. Afterwards I updatedwit-bindgen'srustandrust-guestcrates to add adepsoption to the macro and use the updatedwit-parsercrate. I have not yet looked into adding support to other wit-bindgen crates or wasmtime.In the end the required changes seem to be minimal but the size/depth of these crates is quite large so I am not sure which dependents all would need to change. I'll look into making a PR in the wasm-tools repo first and will go from there.
mkatychev commentedon Sep 22, 2026
Thanks for taking a crack at this!
Ideally this should be solved my a package manager like wkg to allow it to deal with this. Ideally I'd like the generated deps to live in
OUT_DIRso that the dependency tree can be resolved in an isolated space for each possible union/disjoint case.celarye commentedon Sep 23, 2026
As in a single
globalshared dependency directory?Iirc wkg only auto downloads and writes to
{wit_path}/depsat this moment. I guess having that support a deps directory parameter would be nice as well.mkatychev commentedon Sep 23, 2026
@celarye it's a bit more flexible now; disclaimer: I'm a wkg maintainer. With the addition of wkg workspaces in the last release, I am looking at having a shared deps directory for one or more wit files.
This will involve resolving version conflicts between separate packages in a workspace but ultimately I want to avoid duplicating dependency trees each time
bindgen!orgenerate!is called.celarye commentedon Sep 23, 2026
That’s the reason I want this as well yeah.
Nice that you’re a wkg maintainer, I use
wasm-pkg-clientin my own project and should probably get around to making some feature requests for it 😁.celarye commentedon Sep 24, 2026
I've gone ahead and created a Zulip topic to discuss some design decisions: https://bytecodealliance.zulipchat.com/#narrow/channel/327223-wit-bindgen/topic/Adding.20support.20for.20customizing.20the.20dependency.20dir/with/626609106