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 (https://github.com/pkgjs/parseargs/issues/38#issuecomment-1017327974). 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 and `true` value for all parsed options found in `args`. - e.g. `optionFound: { debug: true, name: true, mult: true }` - `values`: object with properties and values for the parsed options - e.g. `values: { debug: true, name: 'John', mult: ['a', 'b'] }` - `positionals`: array of positionals from `args` - e.g. `positionals: ['alpha']` 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 with `type:'string'`) - `true` for option used as boolean flag (normal case for option with `type:'boolean'`) - array if `multiples:true`, with `true` 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`.