Description
A new attempt to improve the results (#12 #22 #23 #38 #55) prompted by proposed changes to input configuration (#63), and with better understanding of some of original intent (#38 (comment)).
For context, the configuration syntax proposed in #63 is:
parseArgs({
args: process.argv.slice(2),
options: {
foo: {
short: 'f',
type: 'string', // defaults to 'boolean'
multiple: true,
// default: 'bar' - Future iteration
}
},
})
Result Properties
I propose result has properties for:
optionFound
: object with properties andtrue
value for all parsed options found inargs
.- e.g.
optionFound: { debug: true, name: true, mult: true }
- e.g.
values
: object with properties and values for the parsed options- e.g.
values: { debug: true, name: 'John', mult: ['a', 'b'] }
- e.g.
positionals
: array of positionals fromargs
- e.g.
positionals: ['alpha']
- e.g.
This is a rename of flags
to optionFound
. The intent of flags
name was the options without values, but the proposed meaning is all options found in args
as per original proposal.
vs status quo: storing all the options found in optionFound
matches the current implementation, but not the current README examples which are only showing true
for boolean options. See also following section on values.
The optionFound
field is initially redundant and can be calculated from values
. However, it offers a semantic affordance now, and is not redundant if we add support for defaults (or setting known boolean flags to false, say) . Both Command and Yargs did not start out with a concept of whether the option was found in the input args
, and that led to requests later as not possible to tell from a value whether was an explicit default (say for a string) or an implicit default (say for a boolean) or for from the parsed arguments.
Values
I propose values
property holds for an option:
- string for option with a value in
args
(normal case for option withtype:'string'
) true
for option used as boolean flag (normal case for option withtype:'boolean'
)- array if
multiples:true
, withtrue
and/or string elements
The change is storing true
as the value for a found boolean option. I think this is the natural value, and is what other parsing libraries do such as Command and Yargs.
vs status quo: the current README examples are omitting boolean options entirely. The current implementation is storing undefined
rather than true
.