Parse configuration: shorts better than short?

[shadowspawn]

Does it scan better to have the property named shorts? i.e. plural for a collection of short.

const result = parseArgs(process.args, { shorts: { f: 'foo", b: 'bar } });

(I noticed when I wrote first code using short and wanted to write shorts. Ask the question before appears in more places!)

[ljharb]

I don’t see the need for it, and it reads a bit awkwardly because it’s pants.

[aaronccasanova]

I'm a fan of the plural form shorts. Without even looking at the documentation it implies it's a collection of aliases.

[shadowspawn]

and it reads a bit awkwardly because it’s pants

I decided this was a clothing reference and not saying it was "rubbish"? Made me smile either way. 😄

I have spent days working with flags and values in this code, and shorts felt quite natural. (Although I agree shorts is clumsy english taken out of context.)

[ljharb]

yes, i've never heard of "pants" to mean anything but clothing, or the thing a dog does when it's hot :-)

[bcoe]

I have no preference on this one, but find 👖 funny.

[bakkot]

shortNames?

[bcoe]

For consistency, and in pursuit of strict by default, what if we go with:

• values: (rather than withValue) for options that accept a value.
• flags: for options that do not accept a value.
• shorts: for mapping a short option name to a long option name?

Along with renaming a couple arguments, I'm suggesting we always use plural.

[ljharb]

I’d say shortOptions instead of “summer pants”, but otherwise sure.

Alternatively, “values” and “flags” can both be an object of booleans or objects, and the object can have a “short” key to define the short option - then the mapping can be built when needed, and we don’t need to provide it already made.

[shadowspawn]

This issue is moot if we adopt: #63

[shadowspawn]

Closing as #63 has landed.