Skip to content

Add support for short option groups #2

Closed

Description

@bcoe

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

Activity

  1. ljharb commented on Apr 16, 2021

    @ljharb
    Member

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

  2. joesepi commented on May 14, 2021

    @joesepi
    Collaborator

    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.

  3. shadowspawn commented on Nov 14, 2021

    @shadowspawn
    Collaborator

    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:

  4. ljharb commented on Nov 14, 2021

    @ljharb
    Member

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

  5. bcoe commented on Nov 14, 2021

    @bcoe
    CollaboratorAuthor

    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.

  6. changed the title [-]Making a case for short opts[/-] [+]Add support for short options[/+] on Dec 4, 2021
  7. changed the title [-]Add support for short options[/-] [+]Add support for short option groups[/+] on Dec 4, 2021
  8. added this to the Merge into Node.js milestone on Dec 4, 2021
  9. bnb commented on Jan 7, 2022

    @bnb
    Member

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

  10. shadowspawn commented on Jan 9, 2022

    @shadowspawn
    Collaborator

    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

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions