Oscar Spencer (Aug 26 2025 at 19:02): Oscar Spencer (Aug 26 2025 at 19:02):When this project was initially created, we didn't have the wasm32-wasip2 target, and this project was quite helpful in creating wasm components from Rust. Today, this project needs quite a bit of love and dedicated maintainership that may not be worth the effort. This has previously been brought up in threads like #cargo-component > Rust toolchain vs cargo component.
As such, the TSC is considering archiving this project. If anyone ever wanted to pick it back up and fix it up, it could be un-archived in the future.
Are there any thoughts from previous maintainers? cc @Dan Gohman @Yosh Wuyts @Pat Hickey @Calvin Prewitt @Alex Crichton
Alex Crichton (Aug 26 2025 at 19:08):Personally I think this makes sense to do. There's going to be a long tail of documentation to update so I think it'd be good to have two prereqs for this:
Alex Crichton (Aug 26 2025 at 19:08):that'd then enable slowly updating docs over time without having to update everything all at once
Calvin Prewitt (Aug 26 2025 at 19:15):Makes sense to archive. Currently, we lack the resources to support the project. The one thing that I really will miss is cargo component new --target to scaffold out a new component that targets a WIT world.
Bailey Hayes (Aug 26 2025 at 19:17):Not quite the same as cargo component new --target, but for http driven components, this is a great starting point: https://github.com/bytecodealliance/sample-wasi-http-rust
It's easy enough to tweak that template to whatever custom wit you may need.
Calvin Prewitt (Aug 26 2025 at 19:19):Bailey Hayes said:
Not quite the same as
cargo component new --target, but for http driven components, this is a great starting point: https://github.com/bytecodealliance/sample-wasi-http-rustIt's easy enough to tweak that template to whatever custom wit you may need.
Yeah, I meant specifically for custom WIT packages.
Dan Gohman (Aug 26 2025 at 22:27):This makes sense to me too.
Pat Hickey (Aug 26 2025 at 22:48):my proposal is that we can find a way to add that sort of templating in the wit-bindgen-cli rust subcommand
Pat Hickey (Aug 26 2025 at 22:50):thats a very small piece of functionality compared to the current complexity of cargo-component, and it could dovetail well with other features to make wit-bindgen-cli more capable, e.g. giving it library use of wkg so that it can automatically get wasi and other published wits without needing the filesystem.
Pat Hickey (Aug 26 2025 at 22:52):until those ideas are implemented, we should have component-model.bytecodealliance.org have the canonical docs alex suggests, for rust guests it should document that if you're just using wasi you can just cargo add wasi and use the bindings provided by that crate, if you want an even higher level binding for cli or proxy world then cargo add wstd and use that crate, and if you are using your own wits here is how you can put them in the filesystem and invoke wit-bindgen as a proc macro to use them.
Pat Hickey (Aug 26 2025 at 22:53):@Tim Chevalier is on vacation right now but he's been doing excellent work updating the component-model site, we can ask him to work on that when he returns.
Yosh Wuyts (Aug 27 2025 at 15:06):I understand the decision to archive it and support it. Though one thing we will be losing out on because of that is automatic SBOM generation support that we currently use in https://github.com/bytecodealliance/sample-wasi-http-rust
Pat Hickey (Aug 27 2025 at 15:07):does cargo auditable build --target wasm32-wasip2 work for that?
Yosh Wuyts (Aug 27 2025 at 15:07):Oh! Yeah I think it should actually!
Yosh Wuyts (Aug 27 2025 at 15:07):I forgot about that
Yosh Wuyts (Aug 27 2025 at 15:09):Yes, perfect - SBOM support _is_ being upstreamed to Cargo proper right now too (though not just for wasm targets), so that will give us a long term story here too. But in the short term we can just keep pointing at cargo-auditable. I like that ^^
Daniel Macovei (Aug 27 2025 at 16:05):Pat Hickey said:
a very small piece of functionality compared to the current complexity of cargo-component, and it could dovetail well with other features to make wit-bindgen-cli more capable, e.g. giving it library use of wkg so that it can automatically get wasi and other published wits without needing the filesystem.
Would it make sense to go ahead and create an issue for this in wit-bindgen? The one thing that I currently find cargo-component uniquely good at is just fetching the wit I need whenever I run cargo-component build, and this I think would really help with not having to instruct users to run a separate set of wkg commands before doing their build.
Pat Hickey (Aug 27 2025 at 16:50):yeah id like for wit-bindgen cli to be able to do the wkg bits
Pat Hickey (Aug 27 2025 at 16:50):so file an issue describing how youd imagine that working and then others can give real feedback on whether thats a good idea or not
Oscar Spencer (Aug 27 2025 at 19:10):I appreciate the discussion, folks! The TSC will make sure the README and component model book gets updated before we archive the project. Thanks all!
Antoine Lavandier (Sep 19 2025 at 10:07):Hi, I'm using the component model (and hence cargo-component) but I'm not using wasi nor do I plan to ( the targets I use are wasm32v1-none or wasm32-unknown-unknown). In the event of the archival of cargo-component, is there a documented alternative to create components ?
Till Schneidereit (Sep 19 2025 at 10:24):I assume you're using the wit-bindgen macros? In that case, you can use wasm-tools component new to turn your module into a component
Till Schneidereit (Sep 19 2025 at 10:25):it's a good question though whether there might be room for a target like wasm32-unknown-component (probably not quite under that name)
Antoine Lavandier (Sep 19 2025 at 12:22):Till Schneidereit said:
I assume you're using the
wit-bindgenmacros? In that case, you can usewasm-tools component newto turn your module into a component
I was using them but through cargo-component so I didn't realize what was needed to migrate away from cargo-component. Thanks for pointing me in the right direction. I will miss the one stop shop of cargo component build but doing cargo build and then wasm-tools component new is not too bad.
Alex Crichton (Sep 19 2025 at 14:44):If you'd like you can pass -Clinker=wasm-component-ld to skip the wasm-tools component new step, for example:
$ rustc -C linker=wasm-component-ld foo.rs --target wasm32-unknown-unknown && file foo.wasm
foo.wasm: WebAssembly (wasm) binary module version 0x1000d
Are there some early docs demonstrating how to get the same basic functionality of cargo component build with native+additional tools?
Specifically in the case of having the WIT defined on a remote registry like wa.dev
Daniel Macovei (Sep 26 2025 at 16:08):You should be able to get the same functionality by using wit-bindgen's generate macro after using wasm-pkg-tools to fetch all of your wit dependencies. Don't want to clog the cargo-component thread too much with how to use wa.dev specifically, but if you'd like I'd be happy to chat with you over DMs about how you can do what you were doing with cargo-component
Last updated: Dec 06 2025 at 06:05 UTC