Hello,
first of all, I quite like this library, it is really easy to grasp, which is rare in .net world.
There are 2 features though which are a blocker for me to consider using it, so just want to ask if I missed something or not.
Problem 1
One feature which I think is missing is global or persistent options, or did I missed it?
Specified on parent command, accessible to child command (maybe dependency injection can be used here?)
some useful examples
./cmd --log-level=debug subcommand --local-option # set loggin level for all subcommands
./ginit --repo gitlab init --project-type rust ./my_project # set that all subcommands will be run against gitlab
./cmd -q subcommand # no output for all subcommands, only return codes
./cmd --json fetch 34 --include-images # return a JSON string for all subcommands
One way to have global options might be to enable them at the end (before arguments). like e.g. 'npm' handles it
npm -g ls --depth 1 # is an equivalent to
npm ls --depth 1 -g
Problem 2
This library is always parsing options as multiple values, which I think is really unusual (and essentially blocks global options).
I can't remember used it like that in case cli supported commands and subcommands.
How I think this feature is mostly implemented:
./cmd -i test.txt -i test.txt # used e.g. in docker cli
# or
./cmd -i test.txt,test.txt # used in a lot of cli apps + it is native to how powershell handles it
# or
./cmd -i=test.txt,tests.txt # used e.g. in git cli
Just wondering what was the reasoning for this implementation, because going through some modern big CLIs like (kubectl, docker, dotnet, hugo, git, github, az, npm, yarn, cargo, pip, choco, scoop, etc.) it was hard to find similar behaviour. At least for me it is simply not intuitive and more or less unexpected.
Thank you for answers,
Stefan