Build Failure with Inline WIT with `wit-bindgen` about cargo-component

[peterhuene]

@tqwewe

With cargo-component 0.9.0, it now componentizes any core module that has bindings type information present (where previously it required [package.metadata.component] to be present in Cargo.toml for it to componentize).

Please review the release notes as there were quite a few breaking changes relating to bindings in that release.

[peterhuene]

Could you provide the build error you're encountering?

[peterhuene]

The guest project is missing the package metadata that marks it as a component project; currently cargo-component does not attempt to componentize just any wasm target outputs.

If you add [package.metadata.component] to your guest's Cargo.toml, does that workaround the issue?

[tqwewe]

Could you provide the build error you're encountering?

Ah sorry I forgot to add this 🤦
I get an error from wasmtime loading the wasm module:

thread 'main' panicked at host/src/main.rs:27:92:
called `Result::unwrap()` on an `Err` value: failed to parse WebAssembly module

Caused by:
    attempted to parse a wasm module with a component parser
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

If you add [package.metadata.component] to your guest's Cargo.toml, does that workaround the issue?

It does! However, would cargo component be willing to change this behaviour and add the component metadata no matter if the [package.metadata.component] is present?

The reason being is that:

• If someone is compiling their cargo crate with cargo component build, then they'd definitely have the intention of building it as a wasm component.

• I'm building a runtime which uses wasmtime, and users of my runtime will compile their modules as cargo components. However telling them that they need to add an empty [package.metadata.component] to get it working, despite them already using cargo component is just one extra gotchya that seems not too necessary?

  Ideally, they could just use cargo new, and then add crate-type = ["cdylib"], and my macro thalo::export_aggregate!(Foo) and it should work with cargo component build

[esoterra]

Why wouldn't they use cargo component new which sets both the crate-type and adds the required [package.metadata.component] section? As a bonus, it also gives them the opportunity to configure different cargo component values with arguments (e.g. package name, editor, vcs).

Alternatively, they could just use a template you create so you can embed your thalo macro call for them.

[tqwewe]

Why wouldn't they use cargo component new

It would indeed be nice, however it also generates the wit directory, and adds cargo-component-rust to the dependencies, etc. These things aren't needed in my case. I don't want them to be concerned with wit files or anything like that, as my library handles it all.

Alternatively, they could just use a template you create so you can embed your thalo macro call for them.

Also a nice idea, but I wanted to keep things as simple as possible for them. So it's just a regular rust crate, and they need thalo as a dependency. The only complicated thing would be that they need to add the crate-type, but that's just a rust thing with wasm.

As I mentioned, isn't it a little strange to have the behaviour of the cargo component build silently not generate a wasm component if the meta is not defined?
If someone uses the cargo component build command then I'd say it's safe to assume they're definitely expecting the resulting wasm to be a valid wasm component