You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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, or git -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.
I think we agree to support short options.
I think we agree that -foo should be -f-o for shortopts.
I think we agree with @ljharb statement above as well.
Reacted by Jordan Harband, TED Vortex (Teodor-Eugen Duțulescu) and Manuel Spigolon
I agree it was a mistake if -foo can mean anything different than -f -o -o.
I agree in the unconfigured case, where f and o implicitly do not take a value.
To expand though, if option f takes a value then the POSIX specification is that f will get the value oo. This is something which could be done by parseArgs if f is specified in withValue
To expand though, if option f takes a value then the POSIX specification is that f will get the value oo. This is something which could be done by parseArgs if f is specified in withValue
Seems like if you've explicitly configured f to take a value, it wouldn't be too hard to design the parser to accept -foo and -f oo. Perhaps start with the simple behavior of assuming a single dash indicates a series of flags, but consider extending it to support this behavior.
I agree it was a mistake if -foo can mean anything different than -f -o -o.
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 withValue). And last, opting out of anything except plain short options (per @bnb comment).
I am interested in working on this, but happy to leave it for someone else. Don't want to hog all the coding fun. 😄
Activity
ljharb commentedon Apr 16, 2021
I agree it was a mistake if
-foocan mean anything different than-f -o -o.joesepi commentedon May 14, 2021
I think we agree to support short options.
I think we agree that
-fooshould be-f-ofor shortopts.I think we agree with @ljharb statement above as well.
shadowspawn commentedon Nov 14, 2021
I agree in the unconfigured case, where
fandoimplicitly do not take a value.To expand though, if option
ftakes a value then the POSIX specification is thatfwill get the valueoo. This is something which could be done byparseArgsiffis specified inwithValueReferences for POSIX and GNU extensions:
ljharb commentedon Nov 14, 2021
Ok, fair enough that
-f oois a legit value for that as well :-)bcoe commentedon Nov 14, 2021
Seems like if you've explicitly configured
fto take a value, it wouldn't be too hard to design the parser to accept-fooand-f oo. Perhaps start with the simple behavior of assuming a single dash indicates a series of flags, but consider extending it to support this behavior.[-]Making a case for short opts[/-][+]Add support for short options[/+][-]Add support for short options[/-][+]Add support for short option groups[/+]bnb commentedon Jan 7, 2022
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).
shadowspawn commentedon Jan 9, 2022
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
withValue). And last, opting out of anything except plain short options (per @bnb comment).I am interested in working on this, but happy to leave it for someone else. Don't want to hog all the coding fun. 😄