Consider reinstating support for numeric aliases

[rgov]

Even ls takes -1 as an argument. This shouldn't be prohibited.

[75lb]

Numeric aliases were removed for ambiguity reasons. Users passing negative numbers (e.g. -1) were having issues as the lib interpreted them as a short option.

Yes, users could write --number=-1 to avoid the ambiguity but the general preference was make short options alpha-chars only.

[rgov]

I see the conflict but --number -1 is only ambiguous if --number accepts zero arguments, and also there is a short option called -1.

This ambiguity exists for non-numeric values, also. For instance is --suffix -s the same as --suffix=-s or not?

[75lb]

I see the conflict but --number -1 is only ambiguous if --number accepts zero arguments, and also there is a short option called -1.

I see your use case, but this lib provides a means of passing no value (null) to options. All options are nullable. If --number accepts a string value, with this lib it's possible to set null and an empty or populated string.

So passing --plugin (where plugin takes a string) without a value is how a user would say "i don't want a plugin". This behaviour would be broken if we always assumed the next arg (even an option-looking arg like -s or -1) was the option value.

[rgov]

Is this behavior of the library based on any other command line parser? It seems unusual, and leads to more complexity and unexpected conditions. Why wouldn't you just not pass --plugin, or pass some option like --no-plugin, rather than passing --plugin with no value?

Again, I think the library should defer to widely accepted conventions here. If the user wants to add a --plugin option that takes 0 or more options, ok, that could be done like argparse's nargs='*'. But it's an irregular way of doing this, and a more sensible way to do it is to set the default value of the plugin option to null or false or whatever.

[75lb]

I will change the behaviour if it is beneficial to do so. So are numeric short options an important requirement for you?

--number -1 is only ambiguous if --number accepts zero arguments and also there is a short option called -1.

I agree there is an opportunity to improve the current behaviour here, by making the checks you describe above to help decide whether the user meant to supply -1 as a numeric value or short option..

[rgov]

It's not a requirement for anything I am developing currently, but it would be good for Node to have argument parser that can be relied on to be correct and consistent with conventions.

I cannot think of a time I have passed a negative value on the command line, but I have used ls -1; git-diff supports -1, -2, and -3, and ssh supports -4 and -6 (as do some other networking tools, like nc).