Priority
Medium — CLI usability, safer scripts, and clearer diagnostics.
Context
Most command parsers use the shared helper consumeValueFlag(args, index, name, allowEmptyEquals) in cmd/gowdk/flags.go. When the flag appears as --flag <value>, the helper accepts the next argument unconditionally as the value.
Current behavior by inspection:
if arg == name {
if index+1 >= len(args) {
return "", index, true, true
}
return args[index+1], index + 1, true, false
}
This means a command such as:
gowdk build --out --app .gowdk/app page.gwdk
can parse --app as the value of --out rather than reporting that --out is missing a value.
Problem
Accepting the next flag-looking token as a value creates confusing and potentially unsafe command behavior.
Consequences:
- A typo or missing value can shift the rest of the command line.
- The resulting error may be far from the real mistake.
- Output paths can accidentally become strings such as
--app or --bin.
- Scripts that expect standard flag parsing behavior become harder to debug.
- Each command that uses
consumeValueFlag inherits the ambiguity.
Proposed direction
Teach value-flag parsing to reject another flag-looking token when the flag requires a value, unless the specific flag explicitly allows dash-prefixed values.
Possible model:
type valueFlagPolicy struct {
AllowEmptyEquals bool
AllowDashValue bool
}
The common default should be AllowDashValue: false for path, config, env-file, module, target, address, and output flags.
Acceptance criteria
Non-goals
Related
Priority
Medium — CLI usability, safer scripts, and clearer diagnostics.
Context
Most command parsers use the shared helper
consumeValueFlag(args, index, name, allowEmptyEquals)incmd/gowdk/flags.go. When the flag appears as--flag <value>, the helper accepts the next argument unconditionally as the value.Current behavior by inspection:
This means a command such as:
can parse
--appas the value of--outrather than reporting that--outis missing a value.Problem
Accepting the next flag-looking token as a value creates confusing and potentially unsafe command behavior.
Consequences:
--appor--bin.consumeValueFlaginherits the ambiguity.Proposed direction
Teach value-flag parsing to reject another flag-looking token when the flag requires a value, unless the specific flag explicitly allows dash-prefixed values.
Possible model:
The common default should be
AllowDashValue: falsefor path, config, env-file, module, target, address, and output flags.Acceptance criteria
--flag --otherreports a missing value for--flagby default.--flag=-valueremains possible only for flags that explicitly allow dash-prefixed values.consumeValueFlagare audited and assigned a value policy.build,check,serve,audit,test,clean,dev, andpreviewforwarded flags.Non-goals
Related