feat: allow disabling duplicate-arguments-array

[laggingreflex]

For yargs#530

Lets you disable "duplicates" behaviour

yargsParser('-x 1 -x 2')
// => {x: [1, 2]}

yargsParser('-x 1 -x 2', {configuration:{'duplicate-arguments-array': false}})
// => {x: 2}

[bcoe]

Great, that's about as simple as I was hoping it would be 👍

[bcoe]

@laggingreflex awesome! thanks for the contribution.

If you wouldn't mind adding a test, so that we stay at 100% coverage, and adding a note about this configuration option in the docs, we'll get this landed ASAP.

[laggingreflex]

This has a slight problem though... it requires you to put {"yargs": {"duplicate-arguments-array": false}} in package.json due to how yargs passes "configuration" to yargs-parser. Any suggestions to specify this config elsewhere? Or should it be handled in yargs?

[bcoe]

@laggingreflex you can also manually pass configuration to yargs-parser, which is how yargs actually does it 😄

https://github.com/yargs/yargs-parser/blob/master/test/yargs-parser.js#L1777

☝️ you should be able to crib that test.

[laggingreflex]

Can the consumers of yargs be able to pass that configuration to yargs-parser though? Because I originally intended to fix yargs#530 with this.

import yargs from 'yargs'

const config = yargs(???).parse('-x 1 -x 2');

It seemed to me the only way for a yargs user to pass this configuration would be by using package.json way - due to how yargs passes "configuration" to yargs-parser ... unless I'm missing something?

[bcoe]

@laggingreflex yargs' is smart enough to read configuration from your projects own package.json; so once you add this setting, a user who wants this behavior, simply needs to add:

{ "yargs": { "duplicate-arguments-array": false } }

To their project's own package.json.

[bcoe]

@laggingreflex I'm really happy with this, will work on getting this landed ASAP.

[bcoe]

@laggingreflex mind rebasing, I think I landed your other pull request in the wrong order.

[laggingreflex]

That one (#71) included this one (#67) so now both are applied, however the resultant commit's message (0f0fb2d) only reflects #71 (changes from both are still applied though). Would rebasing still help?

[bcoe]

@laggingreflex if you checkout master, and rebase this branch against it, it'll do the write thing and make it so this can be landed -- If you don't, I can rebase on another branch for you, but it changes the commit history a bit.

[laggingreflex]

This already has been landed.

#71 included commits for both this (#67) and itself so as far as the matter is of landing this PR, it has already been done; it was included in #71 and the changes have landed successfully.

The only (minor?) problem is that the two commits have been squashed into one 0f0fb2d which makes no mention of this PR (#67), but only that of #71 (in the commit message). If it's not a big problem then you may close this PR. If however you do want separate commits then I think you probably will need to re-write history a bit. I did try to rebase but it gives me "nothing to commit", because like I said, the changes have already landed in latest master.