Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: strict should fail unknown arguments #1977

Merged
merged 3 commits into from Jul 11, 2021
Merged

fix: strict should fail unknown arguments #1977

merged 3 commits into from Jul 11, 2021

Conversation

jly36963
Copy link
Contributor

@jly36963 jly36963 commented Jul 4, 2021

Addresses: #1861

As always, let me know if I need to change/add/fix anything.

Issue

This should fail:

const argv = yargs.strict().parse('foo');
console.log(argv) // { _: [ 'foo' ], '$0': 'example.js' }

Neither unknownArguments nor unknownCommands catch extra args when commandKeys.length is 0.

Fix

I added a block to check if there are any elements in argv that aren't in currentContext.commands. I made sure to tolerate args when yargs.demand(number) is called, when the number of args falls within the min/max range.

This shouldn't fail:

const argv = yargs.strict().demand(1).parse('foo');
console.log(argv) // { _: [ 'foo' ], '$0': 'example.js' }

Note

I don't understand the demand logic well (as it's deprecated and not in the docs), so I'm not sure if the slice in this line will always be correct:

I saw that a few other places do something similar.

@bcoe
Copy link
Member

bcoe commented Jul 8, 2021

@jly36963 thanks for digging into this, will make an effort to review this week 👍 It's great to start squashing some of the long standing bugs.

@bcoe
Copy link
Member

bcoe commented Jul 10, 2021

@biggianteye, @brlodi, I've published @jly36963's fix to yargs@next, mind trying it out and seeing if this approach would work for your application?

npm i yargs@next, or npm i yargs@17.0.2-candidate.

@biggianteye
Copy link

@biggianteye, @brlodi, I've published @jly36963's fix to yargs@next, mind trying it out and seeing if this approach would work for your application?

npm i yargs@next, or npm i yargs@17.0.2-candidate.

I've just tested this version with the code I used in the bug report and it is now working as expected. Thanks!

$ node index.js foo
Options:
  --help     Show help                                                 [boolean]
  --version  Show version number                                       [boolean]

Unknown argument: foo

@bcoe bcoe merged commit c804f0d into yargs:master Jul 11, 2021
@jly36963 jly36963 deleted the fix-strict-false-negative-bug branch July 11, 2021 23:15
kevinoid added a commit to kevinoid/hub-ci-status that referenced this pull request Aug 5, 2021
The problems which previously motivated me to switch from commander to
yargs have been solved (by the addition of .exitOverride() and
.configureOutput()).  Commander has more flexibility than yargs for
option processing using .on('option'), which can be used for options
which are sensitive to ordering or have more complicated handling.  It
is also much simpler and has less exotic behavior that needs to be
disabled (see all the yargs options which were set).  Finally, it is
about 1/6 the total size.

Also, for this project specifically, yargs@17.1.0 broke positional
argument parsing due to yargs/yargs#1977.  Since the argument is
optional, `.demand()` is not appropriate (it's also deprecated).  It
appears the correct fix would be to add a default command and define the
positional argument on that.  However, I'm done dealing with yargs
breakage, and switching to Commander will a better return on effort.

Signed-off-by: Kevin Locke <kevin@kevinlocke.name>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants