Survey of option-argument behaviours #79

Activity

1. Eomm commented on Mar 12, 2022

   

   Eomm

   on Mar 12, 2022

   Collaborator

   More actions

   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
2. shadowspawn commented on Mar 13, 2022

   

   shadowspawn

   on Mar 13, 2022 · Hidden as outdated

   Author

   show commentMore actions
3. aaronccasanova commented on Mar 13, 2022

   

   aaronccasanova

   on Mar 13, 2022

   Last edited by aaronccasanova

   Collaborator

   More actions

   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}`)
   }