cargo-semver-checks
cargo-semver-checks copied to clipboard
Skip bin-only targets in `--workspace` runs
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 amain.rs
it's assumed to have a[[bin]]
with the same name as the crate, and if it has alib.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.
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.
Also related to #86.
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.
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.
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.