Unexpected behavior when following the guide to create a component that requires `wasi:http` with Rust

[ThorstenHans]

I was following this guide available at https://component-model.bytecodealliance.org/language-support/rust.html to build a simple component in Rust.

My intention was to export an interface providing a single operation and to import wasi:[email protected]. I updated tooling according to the introduction section of bespoke guide.

Environment

Component	Version
Host OS	darwin 24.6.0
Rust	1.86.0
Cargo Component	0.21.1
wasm-tools	1.236.1
wkg	0.12.0

What I did (steps to reproduce)

I followed the instructions in the guide:

# Create a new component
cargo component new foo --lib && cd foo

I added my WIT like:

package lorem:[email protected];

interface foo {
    foo: func(a: u32, b: u32) -> result<u32>;
}

world fooer {
    export foo;
    import wasi:http/[email protected];
    import wasi:http/[email protected];
}

To my surprise, the documentation mentioned this:

This section is about importing custom WIT interfaces from library components. By default, cargo-component imports any required WASI interfaces for us without needing to explicitly declare them.

(See this deep-link: https://component-model.bytecodealliance.org/language-support/rust.html#importing-an-interface)

So, naive me quickly updates the package reference in Cargo.toml to lorem:fooer and tries a cargo component build which ends up presenting this error:

error: failed to create a target world for package `foo` (/Users/thorsten/dev/foo/Cargo.toml)

Caused by:
    0: failed to merge local target `/Users/thorsten/dev/foo/wit`
    1: package 'wasi:[email protected]' not found. known packages:
           lorem:[email protected]

            --> /Users/thorsten/dev/foo/wit/world.wit:9:12
             |
           9 |     import wasi:http/[email protected];
             |            ^--------

Looking through the issues of the component-docs repo, I discovered this issue comment referencing wkg wit fetch which pulled all necessary dependencies:

tree wit                                                                                                                                                
wit
├── deps
│   ├── wasi-cli-0.2.3
│   │   └── package.wit
│   ├── wasi-clocks-0.2.3
│   │   └── package.wit
│   ├── wasi-http-0.2.3
│   │   └── package.wit
│   ├── wasi-io-0.2.3
│   │   └── package.wit
│   └── wasi-random-0.2.3
│       └── package.wit
└── world.wit

Running another cargo component build still showed the same error message.

So, I manually added the dependencies in Cargo.toml and tried cargo component build again. However, the error remained the same.

IMO, this is way to hard, especially because the docs mention that it should just work ™️

Is there anything I did wrong on my end?

I totally agree with the statement in the docs, building a new component that relies on WASI APIs should just work and not require any "tinkering"

How I ended up generating a valid WIT world

What worked for me was using wams-tools component wit to generate a working, holistic new WIT world.

[vados-cosmonic]

Hey @ThorstenHans, sorry for the inconvenience! So wasm-tools component wit will normally just print the resolved WIT world -- wkg wit fetch should have been enough to pull the WIT and be able to use it.

Were you by chance aware of this guide:

https://github.com/bytecodealliance/sample-wasi-http-rust

I think it might be easier to follow, and clearly the Rust guide we have on the docs is in need of review.

[ThorstenHans]

@vados-cosmonic yeah I was also expecting wkg wit fetch being enough, it pulls the deps and populates the entire dependency chain correctly. However cargo component build is not able to find the wasi:* dependencies.

I guess it's more or less the note (which I quoted) that made me think "cool this became a smoother experience"...

I'll give the other guide a try and cycle back

[vados-cosmonic]

Definitely agree -- I'm somewhat surprised it wasn't enough.

I guess it's more or less the note (which I quoted) that made me think "cool this became a smoother experience"...

This definitely seems like we have room to improve there.

Would really appreciate a PR if you find what was different there between sample-wasi-http-rust and what we have in the guide 🙇 . We should be on the same versions of the upstream deps, so I'm wondering what it could be but I haven't actually dug in yet!

[pchickey]

For what its worth, we believe cargo-component could make things a lot easier for the user, but its been essentially unmaintained around a year now for lack of resources, and lots of other things in the ecosystem have improved around it in the meantime.

Personal opinions: I dont use cargo-component (barring major improvements) and don't recommend anyone else to. I'd change the docs at this point to have users compile with plain old cargo build --target wasm32-wasip2 and to use the wasi crate when they want to import wasi interfaces, rather than try to manage those wits manually.