Repository navigation
feat: support single dash as option value for long option - #472
Merged
shadowspawn merged 1 commit intoOct 10, 2026
Merged
Conversation
shadowspawn
force-pushed
the
feature/dash-with-long-option
branch
from
April 15, 2023 02:17
3d763e0 to
877c819
Compare
shadowspawn
marked this pull request as ready for review
April 15, 2023 02:20
Member
Author
shadowspawn
force-pushed
the
feature/dash-with-long-option
branch
from
August 15, 2025 02:54
877c819 to
b1a0d98
Compare
Member
Author
|
Manually rebased onto esm-only code |
OrKoN
added a commit
to ChromeDevTools/chrome-devtools-mcp
that referenced
this pull request
Oct 14, 2026
`chrome-devtools fill 1 <uid> -` reported success but cleared the field, `type_text 1 -` typed an empty string, and values like `--weird` could not be passed at all, not even after `--`. yargs re-parses command positionals as `--name value` pairs. In that pass yargs-parser treats any value starting with `-` (other than a negative number) as the next flag and substitutes the string default `''`. yargs also never fills positionals from the tokens after `--`. Neither can be fixed via configuration (`unknown-options-as-args` and `nargs` hit the same re-parse), and the upstream fix for the lone `-` (yargs/yargs-parser#472) is unreleased and only covers that one case. The CLI now shields such tokens before yargs sees them: a lone `-` is always shielded, and everything after the first `--` is shielded with the separator dropped. Shielded tokens are replaced by opaque placeholders and restored when building the tool arguments. Unknown flags such as `--weird` or `--pageid` without `--` are still rejected by strict mode; the error tip and docs/cli.md now explain the `--` form. Related upstream issues: - yargs/yargs#1312 - yargs/yargs#1821 - yargs/yargs-parser#472 Fixes #2984
OrKoN
added a commit
to ChromeDevTools/chrome-devtools-mcp
that referenced
this pull request
Oct 14, 2026
`chrome-devtools fill 1 <uid> -` reported success but cleared the field, `type_text 1 -` typed an empty string, and values like `--weird` could not be passed at all, not even after `--`. yargs re-parses command positionals as `--name value` pairs. In that pass yargs-parser treats any value starting with `-` (other than a negative number) as the next flag and substitutes the string default `''`. yargs also never fills positionals from the tokens after `--`. Neither can be fixed via configuration (`unknown-options-as-args` and `nargs` hit the same re-parse), and the upstream fix for the lone `-` (yargs/yargs-parser#472) is unreleased and only covers that one case. The CLI now shields such tokens before yargs sees them: a lone `-` is always shielded, and everything after the first `--` is shielded with the separator dropped. Shielded tokens are replaced by opaque placeholders and restored when building the tool arguments. Unknown flags such as `--weird` or `--pageid` without `--` are still rejected by strict mode; the error tip and docs/cli.md now explain the `--` form. Related upstream issues: - yargs/yargs#1312 - yargs/yargs#1821 - yargs/yargs-parser#472 Fixes #2984
OrKoN
added a commit
to ChromeDevTools/chrome-devtools-mcp
that referenced
this pull request
Oct 14, 2026
`chrome-devtools fill 1 <uid> -` reported success but cleared the field, `type_text 1 -` typed an empty string, and values like `--weird` could not be passed at all, not even after `--`. yargs re-parses command positionals as `--name value` pairs. In that pass yargs-parser treats any value starting with `-` (other than a negative number) as the next flag and substitutes the string default `''`. yargs also never fills positionals from the tokens after `--`. Neither can be fixed via configuration (`unknown-options-as-args` and `nargs` hit the same re-parse), and the upstream fix for the lone `-` (yargs/yargs-parser#472) is unreleased and only covers that one case. The CLI now shields such tokens before yargs sees them: a lone `-` is always shielded, and everything after the first `--` is shielded with the separator dropped. Shielded tokens are replaced by opaque placeholders and restored when building the tool arguments. Unknown flags such as `--weird` or `--pageid` without `--` are still rejected by strict mode; the error tip and docs/cli.md now explain the `--` form. Related upstream issues: - yargs/yargs#1312 - yargs/yargs#1821 - yargs/yargs-parser#472 Fixes #2984
OrKoN
added a commit
to ChromeDevTools/chrome-devtools-mcp
that referenced
this pull request
Oct 14, 2026
`chrome-devtools fill 1 <uid> -` reported success but cleared the field, `type_text 1 -` typed an empty string, and values like `--weird` could not be passed at all, not even after `--`. yargs re-parses command positionals as `--name value` pairs. In that pass yargs-parser treats any value starting with `-` (other than a negative number) as the next flag and substitutes the string default `''`. yargs also never fills positionals from the tokens after `--`. Neither can be fixed via configuration (`unknown-options-as-args` and `nargs` hit the same re-parse), and the upstream fix for the lone `-` (yargs/yargs-parser#472) is unreleased and only covers that one case. The CLI now shields such tokens before yargs sees them: a lone `-` is always shielded, and everything after the first `--` is shielded with the separator dropped. Shielded tokens are replaced by opaque placeholders and restored when building the tool arguments. Unknown flags such as `--weird` or `--pageid` without `--` are still rejected by strict mode; the error tip and docs/cli.md now explain the `--` form. Related upstream issues: - yargs/yargs#1312 - yargs/yargs#1821 - yargs/yargs-parser#472 Fixes #2984
OrKoN
added a commit
to ChromeDevTools/chrome-devtools-mcp
that referenced
this pull request
Oct 14, 2026
`chrome-devtools fill 1 <uid> -` reported success but cleared the field, `type_text 1 -` typed an empty string, and values like `--weird` could not be passed at all, not even after `--`. yargs re-parses command positionals as `--name value` pairs. In that pass yargs-parser treats any value starting with `-` (other than a negative number) as the next flag and substitutes the string default `''`. yargs also never fills positionals from the tokens after `--`. Neither can be fixed via configuration (`unknown-options-as-args` and `nargs` hit the same re-parse), and the upstream fix for the lone `-` (yargs/yargs-parser#472) is unreleased and only covers that one case. The CLI now shields such tokens before yargs sees them: a lone `-` is always shielded, and everything after the first `--` is shielded with the separator dropped. Shielded tokens are replaced by opaque placeholders and restored when building the tool arguments. Unknown flags such as `--weird` or `--pageid` without `--` are still rejected by strict mode; the error tip and docs/cli.md now explain the `--` form. Related upstream issues: - yargs/yargs#1312 - yargs/yargs#1821 - yargs/yargs-parser#472 Fixes #2984
zjdCander
pushed a commit
to zjdCander/chrome-devtools-mcp
that referenced
this pull request
Oct 14, 2026
…hromeDevTools#3084) `chrome-devtools fill 1 <uid> -` reported success but cleared the field, `type_text 1 -` typed an empty string, and values like `--weird` could not be passed at all, not even after `--`. yargs re-parses command positionals as `--name value` pairs. In that pass yargs-parser treats any value starting with `-` (other than a negative number) as the next flag and substitutes the string default `''`. yargs also never fills positionals from the tokens after `--`. Neither can be fixed via configuration (`unknown-options-as-args` and `nargs` hit the same re-parse), and the upstream fix for the lone `-` (yargs/yargs-parser#472) is unreleased and only covers that one case. The CLI now shields such tokens before yargs sees them: a lone `-` is always shielded, and everything after the first `--` is shielded with the separator dropped. Shielded tokens are replaced by opaque placeholders and restored when building the tool arguments. Unknown flags such as `--weird` or `--pageid` without `--` are still rejected by strict mode; the error tip and docs/cli.md now explain the `--` form. Related upstream issues: - yargs/yargs#1312 - yargs/yargs#1821 - yargs/yargs-parser#472 Fixes ChromeDevTools#2984
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
1 participant
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.
There is a popular issue against yargs asking about using single dash for stdin. In fact this is already implemented and tested in
yargs-parserfor short options and positionals, and just needed a small tweak to work with long options.yargs/yargs#1312