PR #99 removes the --ecosystem flag from check and list, on the grounds that it parsed, was advertised in --help as restricting the run, and was read by nothing. That is the right call for a flag that lies, but it leaves two loose ends.
1. The requirement is still open
docs/dependable-prd.md specifies the flag in three CLI synopses:
--ecosystem <eco> Only check specified ecosystem(s) [default: all]
The PRD is a requirements draft, not user documentation, so the entry describes something intended rather than something shipped — which is why PR #99's documentation pass correctly left it alone. But the requirement is now easy to meet and more useful than it was: V1 was Rust-only, so a filter had nothing to filter, whereas the tool now reads ten ecosystems and a monorepo run can legitimately want one of them.
The plumbing already exists. collect_manifests takes an &|ecosystem| -> bool predicate, which run_check and run_list already supply from cfg.ecosystem_enabled(ecosystem). Restoring the flag means composing the requested ecosystem into that same predicate, and Ecosystem already derives Deserialize, so clap can parse the value into the enum rather than into Option<String> as before.
Worth deciding at the same time: whether the flag is repeatable (--ecosystem rust --ecosystem npm), and what an ecosystem that matches no discovered manifest should do — exit 0 quietly, or say it found nothing of that kind, which is the more honest answer and matches how list already reports an ecosystem that is switched off.
2. The removal is a breaking CLI change carried by a fix: commit
45a9742 fix(cli): stop the config layer silently disarming the gate it was given removes the flag as one part of a larger config-validation fix. Anyone whose script passes --ecosystem gets error: unexpected argument where they previously got a silent no-op.
Because the commit is fix: rather than fix!:, release-plz will compute a patch bump for a release that changes the CLI's accepted arguments. The commit is already pushed and PR #99 is open, so rewriting the message is not on the table; the options are to accept the patch bump, to override the version on the release PR, or to close this issue first so the flag never actually disappears from a published version.
The removal is disclosed in PR #99's body under its breaking-changes section, so nothing here is hidden — this issue exists so the decision is tracked somewhere other than a merged PR body.
PR #99 removes the
--ecosystemflag fromcheckandlist, on the grounds that it parsed, was advertised in--helpas restricting the run, and was read by nothing. That is the right call for a flag that lies, but it leaves two loose ends.1. The requirement is still open
docs/dependable-prd.mdspecifies the flag in three CLI synopses:The PRD is a requirements draft, not user documentation, so the entry describes something intended rather than something shipped — which is why PR #99's documentation pass correctly left it alone. But the requirement is now easy to meet and more useful than it was: V1 was Rust-only, so a filter had nothing to filter, whereas the tool now reads ten ecosystems and a monorepo run can legitimately want one of them.
The plumbing already exists.
collect_manifeststakes an&|ecosystem| -> boolpredicate, whichrun_checkandrun_listalready supply fromcfg.ecosystem_enabled(ecosystem). Restoring the flag means composing the requested ecosystem into that same predicate, andEcosystemalready derivesDeserialize, so clap can parse the value into the enum rather than intoOption<String>as before.Worth deciding at the same time: whether the flag is repeatable (
--ecosystem rust --ecosystem npm), and what an ecosystem that matches no discovered manifest should do — exit 0 quietly, or say it found nothing of that kind, which is the more honest answer and matches howlistalready reports an ecosystem that is switched off.2. The removal is a breaking CLI change carried by a
fix:commit45a9742 fix(cli): stop the config layer silently disarming the gate it was givenremoves the flag as one part of a larger config-validation fix. Anyone whose script passes--ecosystemgetserror: unexpected argumentwhere they previously got a silent no-op.Because the commit is
fix:rather thanfix!:, release-plz will compute a patch bump for a release that changes the CLI's accepted arguments. The commit is already pushed and PR #99 is open, so rewriting the message is not on the table; the options are to accept the patch bump, to override the version on the release PR, or to close this issue first so the flag never actually disappears from a published version.The removal is disclosed in PR #99's body under its breaking-changes section, so nothing here is hidden — this issue exists so the decision is tracked somewhere other than a merged PR body.