-
-
Notifications
You must be signed in to change notification settings - Fork 76
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Skip bin-only targets in --workspace
runs
#163
Comments
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 What would change my answer is when we start checking feature flags. I think I still lean towards erroring for |
Let's make checking bin-only crates an error, and make 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. |
--workspace
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. |
--workspace
--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:
--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.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.
The text was updated successfully, but these errors were encountered: