I have an fs-export component that exports wasi run, fs/types, fs/preopens and imports wasi run. I have another fs-read that exports wasi run and imports wasi fs/types, fs/preopens. If I wac plug fs-read into fs-exports the wasi run plumbs up as expected but (also as expected for plug) wasi fs/types, fs/preopens isn't (all the wasi fs imports go top-level and my vfs is ignored).
I'm guessing I'll have streams / poll issues (which insights would be helpful) but main question is what does the wac 1ook like for that kind of cross-linking? Hints for debugging / printing the composition graph would also be great!
![]()
This is where I'm starting which I think is equivalent to the plug behavior
// wac compose --dep example:fs-export=../fs-export/dist/main.wasm --dep example:fs-read=../fs-read/dist/main.wasm -o dist/main.wasm composition.wac
package example:composition;
let fs-read-impl = new example:fs-read {...};
let fs-export-impl = new example:fs-export { ...fs-read-impl, ... };
export fs-export-impl...;
Part of this might be how components don't support circular imports, everything is acyclic. Given that it sounds like you've got a circular dependency between components here? If so then wac won't be able to handle that (nor components in general)
Fair enough. Seems like it could be a common pattern that would show up in fully virtualizing a cli tool?
Familiar with any other examples trying to accomplish this pattern, i.e. the goal is an http/proxy component that receives an incoming http request, writes a file to a virtual fs, invokes the composed cli component, and resolves the response to the incoming http request (based on capturing std i/o, reading changes to the vfs, etc)?
@Sy Brand's blog is helpful for understanding the circular dependency constraints! https://tartanllama.xyz/posts/wasm-circular-dependencies/
Last updated: Apr 13 2026 at 00:25 UTC