Skip to content
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

Closed
bcoe opened this issue Apr 16, 2021 · 7 comments · Fixed by #59
Closed

Add support for short option groups #2

bcoe opened this issue Apr 16, 2021 · 7 comments · Fixed by #59
Labels
enhancement New feature or request

Comments

@bcoe
Copy link
Collaborator

bcoe commented Apr 16, 2021

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.

Refs: #1

@ljharb
Copy link
Member

ljharb commented Apr 16, 2021

I agree it was a mistake if -foo can mean anything different than -f -o -o.

@joesepi
Copy link
Collaborator

joesepi commented May 14, 2021

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.

@darcyclarke darcyclarke added the enhancement New feature or request label Oct 27, 2021
@shadowspawn
Copy link
Collaborator

shadowspawn commented Nov 14, 2021

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

References for POSIX and GNU extensions:

@ljharb
Copy link
Member

ljharb commented Nov 14, 2021

Ok, fair enough that -f oo is a legit value for that as well :-)

@bcoe
Copy link
Collaborator Author

bcoe commented Nov 14, 2021

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.

@bcoe bcoe changed the title Making a case for short opts Add support for short options Dec 4, 2021
@bcoe bcoe changed the title Add support for short options Add support for short option groups Dec 4, 2021
@bcoe bcoe added this to the Merge into Node.js milestone Dec 4, 2021
@bnb
Copy link

bnb commented Jan 7, 2022

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).

@shadowspawn
Copy link
Collaborator

shadowspawn commented 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. 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants