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

Change on strict behaivor was a breaking change, a.k.a strict only for unknown options #1701

Closed
fcastilloec opened this issue Jul 28, 2020 · 3 comments · Fixed by #1738
Closed

Comments

@fcastilloec
Copy link

fcastilloec commented Jul 28, 2020

I know issue #1625 is closed and #1626 merged, but this was a breaking change (major version) from what yargs used to do and should have been properly labeled.

I was actually using strict old behavior as the opposite of strictCommand, in other words, strict will only apply to unrecognized options and not commands/arguments.
I had a command that takes various filenames, and I was counting on strict to display an error if the user used an unknown option but not on the filenames, which are seen as unknown arguments now.
Now, I have the opposite problem of #1621, I can't use either .strict() or .strictCommand(), and I can't prevent the user from adding unrecognized options.

A workaround is to using check to manually see any unknow options and throw an error, but this is not ideal, especially because yargs was able to do all this. This becomes even harder if you have many options in your command and you're using aliases and/or dashes.
Perhaps, adding a .strictOption() method might be a good idea.

@bcoe
Copy link
Member

bcoe commented Aug 5, 2020

@fcastilloec we try to avoid it, but sometimes someone is relying on an edge-case of a feature that isn't covered appropriately by tests, and we accidentally break due to an oversight such as this.

I would certainly be open to the idea of adding a new method like .strictOption().

If you have the time, could you submit a failing test case for the behavior was working and began failing for you?

fcastilloec added a commit to fcastilloec/ieeeXploreSearching that referenced this issue Aug 20, 2020
We need to test for unknown options but allow unknown arguments

See yargs/yargs#1701 and yargs/yargs#1710
bcoe added a commit that referenced this issue Sep 8, 2020
Adds strictOptions() as a partner to strictCommands()

Fixes #1701
@bcoe
Copy link
Member

bcoe commented Sep 8, 2020

@fcastilloec please try npm i yargs@next it has the strictOptions functionality.

@fcastilloec
Copy link
Author

fcastilloec commented Sep 8, 2020

@bcoe Thanks! I just tried it and it's working in most cases but I found a bug when combined with: parserConfiguration({'strip-aliased': true}). It's related to case-sensitive options, and of course aliases. Here's some code to reproduce the bug:

yargs(['foo', '-a'])
  .parserConfiguration({ 'strip-aliased': true })
  .strictOptions()
  .option('and', { alias: 'A' })
  .parse();

The previous code should fail but it passes. If you set 'strip-aliased': false then it fails. As you can see, there's something happening with capitalization and aliases.
I'll make sure to copy this code and report this in a new issue report.

See #1739

@bcoe bcoe closed this as completed in #1738 Sep 9, 2020
fcastilloec added a commit to fcastilloec/ieeeXploreSearching that referenced this issue Jan 27, 2021
We need to test for unknown options but allow unknown arguments

See yargs/yargs#1701 and yargs/yargs#1710
fcastilloec added a commit to fcastilloec/ieeeXploreSearching that referenced this issue Apr 6, 2022
We need to test for unknown options but allow unknown arguments

See yargs/yargs#1701 and yargs/yargs#1710
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants