v7.1.5: Reject relationship properties that name several targets

Specs that list several flags in one relationship property, or repeat the property, now fail to load with an error. Before this release, usage accepted them but enforced nothing.

Fixed

• (spec) A relationship property such as conflicts="--b --c" is now rejected when the spec loads (#1599, @jdx). Previously, --b --c was read as one selector that matched no flag, so --a --b and --a --c both parsed without error. Repeating the property (conflicts="--b" conflicts="--c") also loaded, but only the last value was kept. Both forms now produce an error:

  conflicts takes one flag or argument per property, but "--b --c" has several; write them as a child node instead: conflicts "--a" "--b"
  conflicts is given more than once; the second would replace the first, so write several as a child node instead: conflicts "--a" "--b"
  

  This check applies to conflicts, overrides, requires, required_if, required_unless and required_unless_all on flags, and to the same properties except overrides on positional args. A value is refused only if it has more than one word and at least one starts with a dash. Values like conflicts="input file" still refer to a positional named [input file].

  Upgrading: These specs were never enforcing their relationships, so they now need to be rewritten in the child-node form. That form already worked and has not changed:

  flag "--a" {
    conflicts "--b" "--c"
  }

  The flag reference (docs/spec/reference/flag.md) now covers the child-node form and these load-time errors.

Full Changelog: v7.1.4...v7.1.5

💚 Sponsor usage

usage is built and maintained by @jdx, an open source developer at entire.io, the title sponsor of his open source work.

If usage powers CLI specs, docs, or completions for a tool you maintain or use, please consider becoming an individual or company sponsor. Your support funds ongoing development and helps keep usage fast, free, and independent.