Support for short options with numeric values, e.g, -p80 #60

Activity

1. bcoe

   added

   enhancementNew feature or requestNew feature or request

   on Feb 6, 2022
2. bcoe

   assigned

   shadowspawn

   on Feb 6, 2022
3. ljharb commented on Feb 6, 2022

   

   ljharb

   on Feb 6, 2022

   Member

   More actions

   With one dash or two? With one, I’d expect it’s short for -p 80
4. bcoe commented on Feb 6, 2022

   

   bcoe

   on Feb 6, 2022

   CollaboratorAuthor

   More actions

   what should the behavior with two dashes be--p80?
5. ljharb commented on Feb 6, 2022

   

   ljharb

   on Feb 6, 2022

   Member

   More actions

   A long option named “p80”, only.

   👍React with 👍2Reacted by Aaron Casanova and John Gee
6. shadowspawn commented on Feb 6, 2022

   

   shadowspawn

   on Feb 6, 2022

   Collaborator

   More actions

   As per previous comment, I think --p80 is a usage of a long option named p80.

   👍React with 👍2Reacted by Jordan Harband and Manuel Spigolon
7. shadowspawn commented on Feb 6, 2022

   

   shadowspawn

   on Feb 6, 2022

   Collaborator

   More actions

   As for the short option -p80, long reply. My opinion. 😄

   I do not think treating numbers as special for combining with short options is the correct high level approach. It is tempting and it is more familiar, but it is opinionated and breaks some other cases.

   In particular, digits are valid short flags. If p is a flag then expanding -p1 to -p -1 is self consistent.

   One affordance that supporting (any) value directly following a short option allows is supplying negative numbers or other values starting with a dash. So if v expects a value, you can enter -v-123 or -v--warnings. I think of this as the same affordance we have with long options and using =, --value=-123 or --value=--warnings.

   I would prefer to have no support for trailing values than treat numbers specially in this regard. Then we still have a simple self-consistent story. We support grouping short flags. We do/don't support trailing values. No special cases.

   👍React with 👍1Reacted by Shalvah
8. ljharb commented on Feb 6, 2022

   

   ljharb

   on Feb 6, 2022

   Member

   More actions

   I completely agree that if i do -pa or -p1, the only two options for both should be equivalent to either -p -a/-p -1 unconditionally, or, -p a/-p 1 iff a and 1 are not configured as options and also -p is configured as an option with a value.
9. shadowspawn commented on Feb 6, 2022

   

   shadowspawn

   on Feb 6, 2022

   Last edited by shadowspawn

   Collaborator

   More actions

   (Small nit, I disagree with iff a and 1 are not configured as options but save that discussion for if we actually head towards support for trailing values!)
10. ljharb commented on Feb 7, 2022

    

    ljharb

    on Feb 7, 2022

    Member

    More actions

    What i mean is, with zero config, I’d expect them to all be considered as options, not values.

    👍React with 👍1Reacted by John Gee
11. shadowspawn

    removed their assignment

    on Mar 1, 2022
12. shadowspawn commented on Mar 27, 2022

    

    shadowspawn

    on Mar 27, 2022

    Collaborator

    More actions

    Support for trailing values for short options has landed, so current behaviour is:

    const { parseArgs } = require('@pkgjs/parseargs')
    const options = { port: { short: 'p', type: 'string' }};
    console.log(parseArgs({ options, strict: false }));
    

    % node p80.js -p80
    { values: { port: '80' }, positionals: [] }
    % node p80.js -a80
    { values: { '0': true, '8': true, a: true }, positionals: [] }
    
    
13. shadowspawn

    closed this as completedon Mar 30, 2022