This is a proposal for supporting short option groups that is quite simple (which I like), and at the same time agrees with an edge-case documented in yargs-parser -- which make me think it's a reasonable approach (I at least haven't noticed many folks complain about this edge-case in the past).
The implementation
Quite simply, -foo expands out to -f, -o, -o, and each individual value is handled by the next step in the parser.
The interesting edge-case of this is that if withValue is configured for the terminal value in the short option list, and the short-option list is followed by a positional, it will be consumed:
As mentioned, this behavior agrees with unit tests in yargs-parser:
// from yargs' test suite:
it('should set the value of the final option in a group to the next supplied value', function () {
const parse = parser(['-cats', 'meow'])
parse.should.have.property('c', true)
parse.should.have.property('a', true)
parse.should.have.property('t', true)
parse.should.have.property('s', 'meow')
parse.should.have.property('_').with.length(0)
})
~TODO: document this decision in README.~
Fixes #2
This is a proposal for supporting short option groups that is quite simple (which I like), and at the same time agrees with an edge-case documented in
yargs-parser
-- which make me think it's a reasonable approach (I at least haven't noticed many folks complain about this edge-case in the past).The implementation
Quite simply,
-foo
expands out to-f
,-o
,-o
, and each individual value is handled by the next step in the parser.The interesting edge-case of this is that if
withValue
is configured for the terminal value in the short option list, and the short-option list is followed by a positional, it will be consumed:As mentioned, this behavior agrees with unit tests in
yargs-parser
:~TODO: document this decision in README.~ Fixes #2