`cargo component check --workspace` should not generate bindings for workspace members without `[package.metadata.component]` set

[rylev]

I have a workspace that has some components within it so I am using cargo component check --workspace to check that all of the workspace members are working. However, one workspace member is a host and not a guest program. This means it has a wit directory but cargo-component should still treat it as a normal Rust binary and not attempt to generate binaries. Presumably if [package.metadata.component] is not set in the Cargo.toml manifest, then it should be safe to assume that the crate is not meant to be compiled as a component using cargo-component.

[peterhuene]

Not having a [package.metadata.component] section in Cargo.toml used to be the way in which cargo-component determined if it should treat it as a "component" project, for both bindings generation and for componentizing outputs.

However, several users ran into issues with this where they had projects not created by cargo component new (and thus lacked [package.metadata.component] sections), but fully expected cargo component build to generate a component because their outputs were core modules with component metadata custom sections present.

So cargo-component changed to treat a missing [package.metadata.component] section as being defaulted and instead check to see if the output was a core module (with component metadata) for componetization.

However, this meant that bindings had to be generated even when a [package.metadata.component] section was missing, so it treated the presence of a ./wit directory as the "default" input for generating bindings.

One option would be to rename the wit directory in your project to something else; another would be to perhaps add a package.metadata.component.bindings setting to cargo-component that disables bindings generation, which you could add to this particular project to prevent it from generating src/bindings.rs.

[rylev]

Hmmm... The work around that I've temporarily settled on is renaming the wit directory, but this is less than ideal as new comers to the project are likely to wonder why the directory with all the wit files is not called wit as is normally the convention.

The work around of adding an opt-out configuration option would probably work though it does feel strange that in a workspace of 10 crates with wit directories, it would only take a single component crate to require 9 other crates to opt-out of bindings generations.

Another idea would be for cargo-component to look at a [workspace.metadata.components] field in the workspace root which could have an excluded field in the same way that workspaces can have explicitly excluded projects. Then cargo-component only generates bindings for those workspaces members who aren't in the excluded field. This could be slightly nicer than requiring each individual project to opt out as "*" glob patterns could be supported.

One could argue that it would make more sense to rely on workspace members to opt into being treated as components (instead of the wit directory presence heuristic) through a [workspace.metadata.components.included] array, but that might be too annoying.