Closed
Description
I am working through some of the special cases during a refactor of the results code.
parseArgs(['--foo', '--bar'], { withValue: ['foo'] )
This is a case where the parser could behave two ways. The --foo
option is expecting a value, there is an argument available, but the argument looks like an option.
The current implementation is that foo
gets the value undefined
, and --bar
is seen as a flag.
- I think seeing
--bar
as a flag rather than the value is the least surprising behaviour, so just confirming that this is as intended and/or expected by others? - Would it be better if
foo
was an empty string rather thanundefined
? This might be more consistent from a typing point of view. I don't have a wrong preference.
Current behaviour, assuming flags are stored in flags and values are stored in values:
flags // { bar: true } <-- ok?
values // { foo: undefined } <-- or empty string?
If the user wants the --bar
to be the value then they can achieve this with --foo=--bar
.
For comparison:
- In Commander both behaviours are available. An option with a required option-argument does eat the next argument, but an option wth an optional option-argument does not eat arguments that look like options.
- In Minimist, with
foo
configured to be a "string" it gets an empty string as value, and--bar
is parsed as a flag.
Added TL;DR proposal: #25 (comment)
Metadata
Metadata
Assignees
Labels
No labels