Allow subcommands to have alias names

[mlaster]

Since ArgumentParser is case-sensitive, it would be nice to allow commands to have alias names. For example, if I have a subcommand named "fetchResults", if the user types "fetchresults", I would like either of these arguments to run my subcommand.

This would also be useful to have both a verbose subcommand name and a short form like "fr"

[Zoha131]

@natecook1000 I would like to work on this issue. I am some questions in my mind:

1. Would the aliasing be an opt-in feature?
2. Would this only be available for that subcommand whose commandName is not nil?

[MPLew-is]

Just my two cents, I would love the ability to be able to have a parent command be able to define a [String: ParsableCommand] dictionary for its subcommands, regardless of what the auto-inferred or overridden name is. I can't say I've ever had a need do it, but it'd be nice to able to bring in existing Argument Parser code from other projects as subcommands if the need arises, and be able to change their names as needed.

In regards to point 1, I would absolutely think that this should be opt-in somehow so that things "just work" out of the box - it certainly feels more Swifty to have the option requiring more complexity (manual command names) be the one that's opted into, to not overcomplicate getting a project started. And we probably also don't want to break whatever existing code there is that relies on the current API, either, if it can be avoided.

I don't have any concrete ideas about what the implementation of this would look like, but it's certainly something I'd be excited to see!

[ghost]

Another aspect to this which would be nice to have is "forwardable aliasing" — an alias that forwards to another subcommand with some default options already set.

For example, one could define a command alias named "reinstall", which would forward to the "install" command, with the "--reinstall" flag set to true by default.

[natecook1000]

@Zoha131 Thanks for your interest in working on this!

1. Would the aliasing be an opt-in feature?

Yes — I think the aliases could just be an array of strings, with the default as an empty array.

2. Would this only be available for that subcommand whose commandName is not nil?

Right — a nil value for commandName means the primary name should be generated automatically from the type name.

You might want to think about how to present the aliases to users in the help, as well.

@MPLew-is / @ajh17: I'm disinclined to add this kind of aliasing, as it somewhat inverts the command tree metaphor. I think we have enough opportunities with composition that this kind of forwarding can be handled by existing language features. For example, you could create a generic wrapper command that includes another command as an @OptionGroup and then runs it automatically:

struct ForwardingCommand<Base: ParsableCommand>: ParsableCommand {
  static var configuration: CommandConfiguration {
    Base.configuration // might need a little extra something here
  }
  
  @OptionGroup
  var command: Base
  
  mutating func run() throws {
    try command.run()
  }
}

[importRyan]

Enjoying the library. Wanted to say thanks via this issue.

@natecook1000 I'd submit a PR from this branch, but am still sorting how to update completion scripting.

1. Would you be comfortable with an implementation that also offers a hiddenCommandAliases parameter in CommandConfiguration? Showing in --help all capitalizations/options could be distracting in some cases.

2. For help presentation, this simply appends a line that reads ALIASES: b BBQ barbeque. For branching commands, the subcommands section simply lists aliases and the command on the same line. In both, terms are size sorted, then alphabetized.

3. Re: enabling in completion scripting. Reading through docs. Is it that command aliases would each get an identical block _base() { ... } _b() { ... } or is there specific syntax for this concept that I've missed?