Survey of option-argument behaviours

[shadowspawn]

Taking a look at how implementations deal with option-arguments. Some made up terminology to describe the behaviours.

• "greedy" vs "choosy" vs "embedded"
  • greedy: any value consumed with -w VALUE, including starting with hyphen
  • choosy: some values are rejected for -w VALUE, such as starting with hyphen
  • embedded: the only way to supply a value is embedded in the argument, like -wVALUE or --with=VALUE
• "required" vs "optional"
  • required: the option requires an option-argument
  • optional: the option can be used with or without an option-argument

Taking a look at the reference specifications and implementations from #76

POSIX: describes "greedy required" and "embedded optional" GNU: no changes getopt_long: "greedy required" and "embedded optional" Commander: "greedy required" and "choosy optional" Yargs: "choosy required" and "choosy optional" Minimist: "choosy optional" (I didn't see how to make the option-argument required.)

[Eomm]

I must say that I prefer the choosy optional (maybe it is a habit).

Thinking about the target of this module to be used by a wide audience, I would go for the POSIX implementation first

[shadowspawn]

Assuming we actually add strict as discussed elsewhere, the current implementation of parseArgs will offer single behaviour depending on strict setting:

• "choosy required" in strict:true (because will throw an error for missing option-argument)
• "choosy optional" in strict:false (because no error, left to author to sort out)

[aaronccasanova]

Thinking about the target of this module to be used by a wide audience, I would go for the POSIX implementation first

This is where my head's at as well. Not only would following POSIX behavior ("greedy required" and "embedded optional") be familiar and widely understood by the community but it would align the parseArgs implementation to a standard (as opposed to contributors' opinions and observations of other libraries).

Also now that I think about it, with greedy and strict: false wouldn't authors have the most accurate user input (according to their options-configs) and thus be able to throw more informative errors: e.g.

// node choosy.js --foo --bar
const {values} = parseArgs({ strict: false, options: { foo: { type: 'string' } })
// values: { foo: true, bar: true }

The best error handling the author can provide is: Error: The '--foo' option expects a value.

Whereas greedy parse behavior would allow authors (who prefer BYO validation) to state exactly how the input was malformed:

// node greedy.js --foo --bar
const {values} = parseArgs({ strict: false, options: { foo: { type: 'string' } })
// values: { foo: '--bar' }

if (validate(values.foo)) {
  throw new Error(`The '--foo' options expects values to follow pattern X and received ${values.foo}`)
}