chore(deps): update to yargs@15.x.x

[bcoe]

Description of the Change

Updates to mocha to latest version of yargs, a couple tweaks were necessary:

• bugs around number coercion that mocha was bumping into appear to be fixed (retries is always a number now, rather than sometimes being a string).
• mocha seemed to be relying on a bug with the array type, such that in some cases it didn't consume multiple positional arguments -- I've added a config setting greedy-arrays which makes this behavior explicit (the only way to get arrays is --foo --foo --foo, i.e., providing the option multiple times).

Alternate Designs

N/A

Why should this be in core?

Benefits

Gets you up-to-date with yargs.

Possible Drawbacks

Applicable issues

N/A

[coveralls]

Coverage remained the same at 92.9% when pulling db6ab71 on bcoe:update-yargs into 9cbb6f6 on mochajs:master.

[juergba]

@bcoe thank you for this PR.

I will do some testing, meanwhile quite a few things have changed in yargs-parser. And actually we have no need to hurry with these dependency updates.

mocha seemed to be relying on a bug with the array type [...]

We are setting opts.narg = 1 for our string/ number / array options. This has worked in the past, since narg has been parsed before array. Now it's the opposite, array before narg. I have to check wether this is a good thing.
Does narg have any effect on array? Probably not, otherwise we would not need greedy-arrays and could just: array plus opts.narg = 1.

[bcoe]

Now it's the opposite, array before narg. I have to check wether this is a good thing.

I'm somewhat convinced that I'd like to drop the nargs feature, and make arrays explicit, i.e., you need to call:

my-app --reporter html --reporter text

☝️to me this seems more in line with how I would expect to pass arrays to most applications, whereas:

my-app --reporter html text

☝️ is too clever, and doesn't leave a good option for folks who simply want to be able to have guarantees that:

1. an argument defaults to an array.
2. potentially be able to give type hints to an array, e.g., an array of resolved paths.

[juergba]

yargs-parser

array should take precedence over nargs, but enforce nargs

This statement seems to be incorrect?

[bcoe]

This statement seems to be incorrect?

I've made more changes to yargs-parser, such that this statement should be correct see, and #4196

With the update to yargs made here, the behavior when nargs and array are used in conjunction should now be back to what you expected, while still addressing the bug we were attempting to fix.

[juergba]

Thank you.

I did some testing:

• narg: 1 (plus greedy-arrays: true): ok
• narg: 1 plus greedy-arrays: false: ok
• only greedy-arrays: false: some CI test fail

eg. --extension which is string[] and requires one argument.
When no argument is supplied:

• with narg: 1 yargs-parser populates the error object
• without narg: 1 the parsing result is: --extension: [""] (default value for string)

So your last version works well for Mocha, but I'm not yet convinced that removing narg is a good idea. How do you tell an array option one argument is needed? narg: 0 is used also for boolean

[bcoe]

@juergba I'm coming around to your point of view, given we use nargs internally for things like requiesArg, I'm coming around to just making the tests for using array, nargs, and requiresArg in conjunction more explicit, which I'm working on in the PR I shared.

I also like the addition of the NaN special case to indicate requiresArg, as it lets us differentiate between narg of 1 vs., requiresArg use case.

[juergba]

Ok. Btw it's confusing for yargs => nargs and for yargs-parser => narg

[boneskull]

@bcoe can you pls resolve conflicts?

wish the git npm lockfile merge provider was available on GH...

[boneskull]

also, I'm hoping there's a newer release (not a beta)?

[bcoe]

👋 this is a bit stale, yargs@15.x is out of beta and should address this issue now 👌