Closed bcoe closed 2 years ago
With one dash or two? With one, I’d expect it’s short for -p 80
what should the behavior with two dashes be--p80
?
A long option named “p80”, only.
As per previous comment, I think --p80
is a usage of a long option named p80
.
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.
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.
(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!)
What i mean is, with zero config, I’d expect them to all be considered as options, not values.
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: [] }
Seems like a reasonable feature to support which wouldn't step on other parsing goals.
Open question
What do you do with
--p80
?Refs: https://github.com/pkgjs/parseargs/pull/59