Skip to content

Restructure result conventions (again) #70

Closed
@shadowspawn

Description

@shadowspawn

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 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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions