Use createOption() in helpOption() to support custom option flag extraction (+ various improvements)

[aweebit]

Cherry-picked from #1926 for better separation of concerns.

Serves as the base for other PRs dealing with help options (#1931, #1934, #1935) and includes various improvements relevant for all of them. For reasoning behind those improvements, see the commit descriptions.

Has been merged with the already approved tiny fixes PR #1930 because a change introduced there would cause an obscure merge conflict if merged with this PR later.

Problem

Unlike version() using an Option instance returned from createOption() to calculate the version option's names, helpOption() does not call createOption() to calculate the help option's short and long flag and instead simply uses the splitOptionFlags() helper function.

class MyOption extends Option {
  constructor(flags, description) {
    super(flags, description);
    this.long = this.long && `--my-${this.long.slice(2)}`;
  }
}

class MyCommand extends Command {
  createOption(flags, description) {
    return new MyOption(flags, description);
  }
}

const command = new MyCommand();
command.version('1.0.0');
console.log(command._versionOptionName); // '--my-version' as expected
command.helpOption('--custom-help');
console.log(command._helpLongFlag); // '--custom-help' instead of '--my-custom-help'

Solution

Call createOption() from helpOption() and store the returned Option instance in a _helpOption property of the Command instance.

Do not store the individual flags in the _helpShortFlag and _helpLongFlag properties anymore, access them via _helpOption.short and _helpOption.long instead. The reasoning behind this change is the following: in the future, there could be need to access not only the individual flags, but also the originally provided flags, the .name(), the .attributeName() or something else pertaining to the help option. It makes no sense to add a property to the Command instance each time such a property is needed, it is way better to simply store the Option instance.

ChangeLog

Changed

• Breaking: use .createOption() in .helpOption() to support custom option flag extraction

Peer PRs

…solving similar problems

• Allow dynamically updating version number and version option flags and description #1933 (storing the version option instance in _versionOption instead of only the .attributeName() in _versionOptionName)

[aweebit]

I noticed the tests now added in 7335a9c were missing because #1934 did not fail despite not handling obscured help flags correctly.

I am sorry for making this PR a mess, this one should've only included the changes described in the Solution section, and there should've been a different PR based off this one with all the other improvements for #1931, #1934, #1935 to build upon. Unfortunately, it is too late to change this now because too much depends on this PR.

[shadowspawn]

Using a help option rather than tracking help properties separately is something I am somewhat interested in, but more to see than to action for now. So may be referring back to this in future.