-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for short option groups #2
Comments
I agree it was a mistake if |
I think we agree to support short options. |
I agree in the unconfigured case, where To expand though, if option References for POSIX and GNU extensions: |
Ok, fair enough that |
Seems like if you've explicitly configured |
I agree with this. I also think it would be nice if we can allow people to yeet out of this rule if they really want to for their own reasons (the most obvious being legacy commands that are moving to adopt this tooling). |
My order of priorities for short options is plain arg (i.e. single dash followed by single character) working fully, and then short option groups for option flags, and then option with value following in argument (for I am interested in working on this, but happy to leave it for someone else. Don't want to hog all the coding fun. 😄 |
In the FAQ it's mentioned that one of the blockers for short options is
-foo
being treated the same as--foo
. I'd argue that I'd rather people not be able to set-foo
, but that someone can write the command:rm -rf
, orgit -rf ./node_modules
.tldr; I think people know long form arguments take two dashes, and it was a mistake to in yargs/yargs-parser to allow for -foo.
Refs: #1
The text was updated successfully, but these errors were encountered: