Support bindings wrapper crates that can be used in component implementation crates about cargo-component

[landonxjames]

Adding in my use case here. I have a need to make a library that wraps some wasi:http functionality for use in multiple (Rust) components. Specifically I need to implement a replacement http-connector for an SDK I would like to use that is not by default not functoinal in wasm/wasi. At the moment I can't see any way of doing that beyond making my library a kind of no-op component. It would be ideal if I could somehow import the wasi:http functions into my library without having to jump through the build hoops of having a stubbed component for it.

[alec-deason]

I have a use case which I think is hitting this same problem. I would like to implement the same component from several crates but share utility code between them. Having the bindings redefined in each crate makes the types impossible to share (I think) so I need them in a separate crate that all the others can import.

For what it's worth I was able to make that work with a bit of hand tweaking:
I created a shared_bindings crate in my workspace using cargo component new --lib shared_bindings, setup the correct .wit file and generated the bindings with cargo component build then modified the lib.rs to simply export the bindings:

#[allow(warnings)]
mod bindings;

pub use bindings::*;

And modified bindings.rs to make the export! macro public as well as change the Cargo.toml file to make the crate a regular rlib. I was then able to create my implementation crates with cargo component new --lib as usual but instead of declaring the bindings module from the local bindings.rs I imported the shared_bindings crate and used those definitions. cargo component --build works and creates usable wasm files, at least in my fairly simple test case.

Not particularly ergonomic as is but it seems to indicate that the changes to the tooling needed to support this are pretty minimal.