Repository navigation
fix(cli): reject invalid/unknown-flag positionals in hand-rolled arg parsers - #222
Merged
Merged
Conversation
❌ Deploy Preview for staging-void-cloud failed.
|
hyfdev
commented
Jun 18, 2026
hyfdev
marked this pull request as ready for review
June 18, 2026 14:53
hyfdev
force-pushed
the
fix/cli-reject-unknown-flags
branch
from
June 18, 2026 16:12
dc538ab to
8a449c2
Compare
Brooooooklyn
approved these changes
Jun 30, 2026
Member
Merge activity
|
…parsers The three hand-rolled CLI parsers swallowed an unknown flag (or other invalid token) as a positional instead of erroring, unlike the parseArgs(strict) parsers and the sibling branches that already guard: - parseProjectArgs status/link/rollback/cancel captured a leading flag as the project name / deployment id (`void project status --foo` returned name='--foo', a bogus slug sent to the platform), though the `delete` branch already rejects unknown flags. - parseDomainArgs captured an unknown flag as the hostname or dropped it. - parseMiddlewareArgs (gen) accepted any name, so `void gen middleware --foo` scaffolded a file literally named `001.--foo.ts` — the sibling gen parsers (model/migration/cron/queue) all validate the name and reject it. Add the leading-dash guard the `delete` branch uses to the four project branches and the domain parser loop, and give parseMiddlewareArgs the same name validation its gen siblings already use.
The name-validation regexes in the gen arg parsers were inline literals, recreating a RegExp on every parser call and duplicating two identical patterns across five sites. Hoist them to two module-level constants (NAME_RE for model/migration, NAME_WITH_HYPHENS_RE for middleware/cron/ queue). Behavior is unchanged (anchored, non-global validators).
Brooooooklyn
force-pushed
the
fix/cli-reject-unknown-flags
branch
from
June 30, 2026 03:41
8a449c2 to
19244d8
Compare
cpojer
pushed a commit
that referenced
this pull request
Sep 11, 2026
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The CLI now rejects a mistyped/unknown flag instead of silently turning it into a project name, hostname, or scaffolded filename.
The bug
Three hand-rolled arg parsers captured an invalid leading-dash token as a positional instead of erroring — unlike every
parseArgs({strict})parser and the sibling branches that already guard:parseProjectArgs(status/link/rollback/cancel):void project status --fooreturnedname: '--foo', a bogus slug then sent to the platform — even though the siblingdeletebranch already rejects unknown flags.parseDomainArgs: an unknown flag was captured as the hostname (or silently dropped).parseMiddlewareArgs(void gen): any name was accepted, sovoid gen middleware --fooscaffolded a file literally named001.--foo.ts— while the sibling gen parsers (model/migration/cron/queue) all validate the name.Expected-correct behavior
A leading-dash / invalid token is not a valid positional → reject it, matching the contract the rest of the CLI already enforces.
Minimal repro
parseProjectArgs(['status', '--foo'])returned{ subcommand: 'status', name: '--foo' }(should throwproject: Unknown flag '--foo'.).The fix
Add the leading-dash guard the
deletebranch already uses to the four project branches and the domain parser loop, and giveparseMiddlewareArgsthe same name regex (/^[a-z_][a-z0-9_-]*$/) its gen siblings already use. No legitimate positional (project slug,dpl_id, DNS hostname, middleware name) starts with-.Tests
Regression tests added (
project-args.test.ts, newdomain-args.test.ts,gen-args.test.ts): 6 unknown-flag rejections that fail onorigin/mainand pass after, plus happy-path/hyphenated-name guards. Local gate: the three arg test files 63/63; full--project unitzero-collateral vs a cleanorigin/mainbaseline (identical pre-existing adapter/init-migration failures, unrelated);packages/voidtypecheck + lint + fmt clean.I enumerated every CLI parser to confirm these were the only three hand-rolled ones still swallowing invalid positionals (the rest use strict
parseArgs, a subcommand allowlist, or a name regex), so the bug class is fully covered.Prepared with AI assistance.