Add support for sharing and stand-alone parsing of subcommands. Warn about parse calls on commands added with .command()

[aweebit]

An extension of #1937 showcasing a better version of the changes I suggested in #1917 (comment).

This was originally a proof of concept PR that expected to give new life to #1917 and #1924.

Now, I would like this PR and #1940 to supersede #1917. See #1917 (comment) for details.

Partially fixes #1916.

ChangeLog

Added

• support for sharing and stand-alone parsing of subcommands
• warnings about parse calls on commands added with .command()

Motivation

• gives meaning to currently meaningless parse calls on subcommands
• the meaning given is what most users probably expect
• makes the error introduced in #1917 unnecessary, and the warning introduced there not absolutely necessary but just useful for chains with .command()

Implementation details

• backwards compatibility is preserved: the behavior has not changed in code using the current and previous versions of the library as intended (only adding commands to one parent and parsing from the parent)
• the implementation is quite low-effort
  • very few code changes
  • unlikely something could go wrong
  • here is a summary:
    • additionally set parent to the invoking parent command at the beginning of _parseCommand()
    • add parents to store all parent commands so that no parent checks have to be moved to parse calls, which I wrongly assumed would be necessary in my comment to #1924 (see how _checkForBrokenPassThrough() is implemented in this PR, for example)
    • add _implicitlyCreated indicating whether the command was created with .command()
    • check its value to warn the developer about parse calls at the end of a .command() chain

Peer PRs

Warnings need to be consistent with…

• Add async custom processing support. Add chainArgParserCalls() for configuration. Additionally await thenable implicit and default option values and thenable default argument values #1915
• React to wrong library usage #1917
• Warn about obscured help option #1931
• Warn about async calls in .parse() #1940

Requires changes when merged with…

• Add .suppressWarnings() for warnings in #1915 #1931 #1938 #1940 #1955

[shadowspawn]

Nice clear labelling as "Proof of concept" and "Draft", and good description to explain.

The approach of having a stable forward/subcommand link while wiring up the reverse/parent links while parsing is an interesting idea. The wiring itself is indeed "low effort".

The downside is a more complex model for maintainers and to a lesser extent authors, to support some exotic reuse configurations.

I am comfortable with the current simple model of one stable tree with matching forwards and backwards links. This POC is not something I am interested in proceeding with at this time.

[aweebit]

Hmm, I expected the already merged commits to not be shown anymore after changing base and merging with the new one. Well, at least the file changes are not cluttered anymore.

[aweebit]

The downside is a more complex model for maintainers and to a lesser extent authors, to support some exotic reuse configurations.

What kind of authors would the more complex model affect? Authors of libraries extending the functionality of Commander somehow? I don't think any maintenance complications are implied for authors of CLI applications using Commander as currently intended (only adding commands to one parent and parsing from that parent) since the change is fully backwards compatible and invisible in such cases (I have even got rid of currentParent in the most recent commit because it was redundant). And if they do parse subcommands from different parents or as stand-alones, then they know what they are doing.

I am comfortable with the current simple model of one stable tree with matching forwards and backwards links. This POC is not something I am interested in proceeding with at this time.

One reason I want to support the exotic reuse configurations is because right now, parsing subcommands as stand-alones is allowed despite being a meaningless operation (since the .parent is not reset to null), so it would be reasonable to forbid it, but there is no good way to do it because parse calls are only supposed to throw errors originating in user code (argParsers, hooks and actions), so warnings have to be used instead, and I would like to avoid that as much as possible.

[aweebit]

The downside is a more complex model for maintainers

I can agree some overhead is introduced for contributors, but really insignificant. Would just have to think whether iterating over parents is more appropriate when using parent in code, that's it.

[aweebit]

I would now like this PR and #1940 to supersede #1917. See #1917 (comment) for details.

[aweebit]

Just a quick note. I keep finding myself putting .parse() at the end of chains that have .command() in them by mistake when writing tests and demos for my pull requests. Introducing warnings about such parse calls would indeed be very, very useful.

[shadowspawn]

This is a useful note, thanks: #1938 (comment)

I added one previous warning because of a mistake I kept making: #1655

[shadowspawn]

These changes are not something I am interested in proceeding with.