Cysharp / ConsoleAppFramework

Zero Dependency, Zero Overhead, Zero Reflection, Zero Allocation, AOT Safe CLI Framework powered by C# Source Generator.
MIT License
1.53k stars 88 forks source link

Alias Commands #124

Open BlackPhlox opened 3 weeks ago

BlackPhlox commented 3 weeks ago

Alias is a great feature for options, so it goes without saying that commands should also be able to. Here's my rendition for how it could look like syntax-wise (based on Cocona):

// Program.cs
var app = ConsoleApp.Create();
app.Add<KeyVaultCommands>("KeyVault").Alias("kv");
app.Run(args);

Produces result, uses , the same as option aliases:

> MyCLI.exe
Usage: [command] [-h|--help] [--version]

Commands:
  keyvault, kv        KeyVault - Manage Azure Key Vault Secrets

Instead of Alias method, as it would have to change Add to not return void, you could also use params to take as Add argument, ie. params string[], but will then not work for the overload, when using a delegate after commandPath:

app.Add<KeyVaultCommands>("KeyVault", "kv");
neuecc commented 3 weeks ago

How common are command aliases? I feel that command aliases are close to being a bad practice, so I'm hesitant to include them. If you could provide some examples showing that they are common and beneficial, I would be willing to reconsider my stance.

BlackPhlox commented 3 weeks ago

It's not common but I see it as being comparable to the shorthands that are usually available with options like: -e | --environment. I'm currently dogfooding changes in my fork, creating a new internal CLI, and I use the alias kv for keyvault, af for azure function etc. as I frequently use those commands a lot and prefer not typing them out. Though you would then properly ask, why not just always have the shorthand command name instead? This is a valid question, though the reason is that I want the full name as well for clarity and not need to have an explanation in the description of the command, which could be used for a more specific message about the command.

Also, note that the way it is currently implemented in #125, is so that it is an optional feature that should not get in the way of the current behavior. However, I haven't benchmarked the performance of the changes.

neuecc commented 2 weeks ago

Thanks. I also saw the PR. I know only a few will use this feature, but I'm OK with the introduction as it does no harm to the general use case.