Return support for multiple character short options

[twalshOG]

I know this change was intentional (#2270), but am hoping the team would reconsider.
A single character can be limiting and result in counterintuitive/weird short parameters.

Real-ish example of where multi-character shorts would be nice:

program
  .option('-k, --kill', 'kill orphaned reports')
  .option(
    '-sk, --skipExtract',
    "don't load results into database; intended for cases where you already have a fully populated database",
  )
  .option(
    '-sd, --skipPublish',
    "don't publish results the overall results; intended for cases where we are to archive the results but not push them to the entire team",
  );

[shadowspawn]

Short options with multiple-characters worked more by accident than being intentionally supported. The README was updated in Commander v3 to make the intended single-character explicit and multiple-characters was added to the deprecated documentation in Commander v9.

PR #599 added support for embedded option values and moved Commander closer to POSIX conventions which only have a single character for a short option.

There have been issues reported where people noted shortcomings in the (unsupported) behaviour: #2211 #2227. Likewise, code added to detect conflicting options did not consider multiple-character short options in #2055.

However, multiple character short options have been used in the wild! 2.4k hits on GitHub with this search

If we allow multiple character short options then I want it to be internally supported and not just work by happy coincidence.

Do you see multiple-character short options being used in popular command-line utilities you use? (Other than npm, which I know uses its own command-line parsing utility with shorthands.)

[shadowspawn]

A historical note after some investigation. Before Commander v5, short options with more than 1 character could not actually be used on the command line. In previous versions an option like -sk was unconditionally expanded to -s -k. So at the time I first noticed it in code in the wild and updated the README, it was not actually functional. Probably the option parsing rework in #1152 made them functional as an unintended side-effect.

[shadowspawn]

Some people were similarly using multiple longs like '--es, --ecmascript': #2270 (comment)

Multiple longs not often used in the wild: search

[twalshOG]

Regardless of the outcome, I respect thoughtfulness put into this issue/design decision.
I do feel compelled to point out that code searches will only find public code, so the number will likely be markedly higher.

[shadowspawn]

Short version: my latest thinking is to add explicit support for a short-ish option, but with double-dash rather than single dash.

Long version

There are strong conventions for short options (POSIX) and long options (GNU). I am uncomfortable about supporting a third and non-standard variation with multi-character short option.

But I appreciate the author desire for a more memorable short-ish option than a single character.

Adding explicit support for a double-dash short-ish option feels like a more pure approach still offering the key benefit. e.g. --es, --ecmascript <year>

There are no new behaviours that need to be decided or described for the short-ish option, and it is full featured. Can you embed option value with a short-ish option? Of course, --es=2018. Can you combined short and short-ish options in a single argument after a single dash? Of course not.

[shadowspawn]

@twalshOG
PR #2312 adds support for a shortish option by using double dash rather than single dash. So following the example in your sample code:

  .option(
    '--sk, --skipExtract',
    "don't load results into database; intended for cases where you already have a fully populated database",
  )

[shadowspawn]

@p3k
PR #2312 adds support for dual long options, to allow a shortish option and a long option. So following your examples:

  .option('--es, --ecmascript')
  .option('--ddsg, --donaudampfschifffahrtsgesellschaft')

[medranocalvo]

In our case we have to maintain compatibility with a suite of existing command line programs. These programs all support various standard options:

• -OAd, enable debugging
• -OAn, set process priority (nice)
• -OAp, set process name
• etc.

This is the standard in this application suite; following POSIX/GNU style would be breaking the local, decades-old standard. While, given the choice, I'd follow usual standards (POSIX/GNU) for command line options, there is not always a choice.

Support for single-dash-multiple-letter options would be a welcome feature which, in my opinion, would make commander.js more widely applicable.