cargo-semver-checks icon indicating copy to clipboard operation
cargo-semver-checks copied to clipboard

Skip bin-only targets in `--workspace` runs

Open obi1kenobi opened this issue 2 years ago • 5 comments

What should cargo-semver-checks' behavior be when asked to semver-check a crate that only has a bin target? (a) It could exit 1 and report an error. (b) It could exit 0 without running any semver checks, and report that this was the case since there was no lib target in the crate. (c) It could run semver checks as if the bin target was a library.

Things to keep in mind:

  • The --workspace flag can implicitly ask cargo-semver-checks to check a bin-only crate, since it asks it to check all crates in the workspace. This makes option (a) unappealing unless we also include logic to skip bin-only crates when --workspace is applied.
  • Crates can have more than one target: both multiple bin targets, as well as a lib target together with one or more bin targets are possible. If a lib target is present, it should obviously be checked. If choosing option (c), should all the bin targets also be checked?
  • Cargo.toml isn't required to have a [lib] or [[bin]] section: if the crate has a main.rs it's assumed to have a [[bin]] with the same name as the crate, and if it has a lib.rs it's assumed to have a [lib] with the same name. This makes it somewhat inconvenient to detect whether a crate with a default target is a lib crate or not, and we'd either need to be extra careful in the implementation or accept that implicit-bin crates might get checked as if they were lib crates.

I'm inclined toward option (b).

Option (c) would require that we check all bin targets present in addition to any lib target, which doesn't seem useful and may be confusing -- and may require adding additional logic if users want to exclude certain bin targets from checking.

And option (a) seems like it would be both more work and also like it might lead to some inconsistency: rustdoc JSON files don't inherently include info on whether they were generated for a lib or bin target, and it's possible to manually generate rustdoc JSON for bin targets and have cargo-semver-checks scan them.

obi1kenobi avatar Oct 30 '22 03:10 obi1kenobi

Related to #162 since the JSON file's name by default is the name of the target, not the name of the crate. By default, lib targets share the name of the crate.

obi1kenobi avatar Oct 30 '22 03:10 obi1kenobi

Also related to #86.

obi1kenobi avatar Oct 30 '22 05:10 obi1kenobi

Checking the API is meaningless and on its own, I think it'd deserve an error. We could have --workspace automatically skip [[bin]] only crates. That should be easy with cargo_metadata as it reports back package information with all of the implicit fields populated for us.

What would change my answer is when we start checking feature flags. I think I still lean towards erroring for [[bin]]]s as the focus is on APIs for crates and not crates generally.

epage avatar Oct 31 '22 12:10 epage

Let's make checking bin-only crates an error, and make --workspace skip them automatically. If --workspace ends up skipping everything, that should be an error too.

Overall, asking for a semver-check that finds nothing that can be checked is an "mismatch between tool capabilities and user expectations" error, not a silent success.

obi1kenobi avatar Jan 08 '23 00:01 obi1kenobi

As of #663 attempting to check bin-only targets is now an error.

I'm planning to start adding workspace-level tests to pin down cargo-semver-checks' behavior in workspaces.

obi1kenobi avatar Feb 13 '24 21:02 obi1kenobi