Fix issue with numeric character in group of options

[elas7]

When checking a group of options, if there is any number in the characters following the key being currently evaluated, then everything after the current key will be set as its value. This happens because the regex that checks for numbers is missing a ^ at the beginning, so strings like 'abc123' are considered numbers.

An issue caused by this is that, for example, calling -abc=123 results in {"_": [], "a": "bc=123"} instead of {"_": [], "a": true, "b": true, "c": 123}

[coveralls]

Coverage remained the same at 100.0% when pulling d527a45 on elas7:fix-group into 48b1e6a on yargs:master.

[bcoe]

part of me would expect this to equal:

a: true
b: true
5: true
n: true
1: true
2: true
3: true

[nexdrew]

This is an odd edge case. I would expect something like -x1 to be parsed as x: 1, which I think is common among most POSIX bins, but I don't know what the typical interpretation of -x1y5 is.

In this test case, I would expect the result to be one of the following:

1. a: true, b: 5, n: 123
2. a: true, b: true, 5: true, n: 123

[bcoe]

To me, option .2. feels a little more useful, I can't think of a situation where I want 5: true but I can imagine a lazy person writing -x1y5 and expecting:

{x: 1, y:5}

[maxrimue]

I would honestly expect it to be parsed like @bcoe noted in the first comment. I've actually not seen it in other bins, but I would expect grouping short options to not offer assigning values at all, because it's not really obvious to which options the values shall apply. As an example:
-xy1 could mean:

1. Assign 1 to x and y, or
2. Assign 1 to y and true to x

Even if we would document it, it's just not obvious if you read something like this.
Additionally, currently we do assigning values to options with either a = or a space:
--value=1 and --value 1
if we now allowed typing values of a certain kind right after the name of the option, wouldn't that kinda break the consistency?

[elas7]

I agree with @maxrimue that we should better not assign values on short option groups based on kinds of values, most of the time it is not really obvious what the user is trying to do.

Yet, the current behavior is that numbers at the end of an options group are set as the value of the last key. Maybe we could add a configuration to yargs-parser to toggle that off?

[bcoe]

@nexdrew mind lending @elas7 and I a second set of eyes?

[bcoe]

@elas7 you've swayed me in your argument for how parsing should be applied. I think it's worth kicking this change to the next major release of yargs however, it has the potential to change parsing behavior in a way that is hard for folks to debug.