Poll: change api for adding command arguments?

[shadowspawn]

The syntax for adding command arguments which have help descriptions is quite different from the rest of the API, and arguments and options are added quite differently although they could be similar. (Prompted by discussion about offering .choices() for arguments in #1458.)

A couple of questions for feedback via reactions or comments.

[shadowspawn]

1. Argument descriptions. Current syntax:

program
  .arguments('<username> [password]')
  .description('test command', {
    username: 'user to login',
    password: 'password for user, if required'
  })

Suggested syntax:

program
  .description('test command')
  .argument('<username>', 'user to login')
  .argument('[password]', 'password for user, if required')

Should .argument(usage, description) replace the use of .description(cmdDesc, argsDesc) for specifying help for command-arguments? 👍 👎

[shadowspawn]

2. Adding arguments. Current syntax:

program
  .arguments('<cmd> [args]');

Suggested syntax:

program
  .argument('<cmd>')
  .argument('[args]');

Should .argument() replace the use of .arguments() for adding command-arguments? 👍 👎

[shadowspawn]

Not huge numbers, but unanimous positive response after a month. (Thanks for feedback.)

1. 8 👍
2. 5 👍

[NicolasThierion]

I found I can coerce options with a function as a third parameter.
Is there any plan to allow argument corecion the same way with this new syntax ?

Eg:

program
  .argument('<username>', 'user to login', (value) => value.toLowerCase())

[shadowspawn]

Yes, planned and done. .argument() supports coercion (custom processing) and default value, following same pattern as .option(). Will be released in Commander v8.

#1508