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: Reworking/improving optionator configuration for --print-config #7206
Conversation
Thanks for the pull request, @platinumazure! I took a look to make sure it's ready for merging and found some changes are needed:
Can you please update the pull request to address these? (More information can be found in our pull request guide.) |
@platinumazure, thanks for your PR! By analyzing the annotation information on this pull request, we identified @christophercrouzet, @mysticatea and @gyandeeps to be potential reviewers |
566e5b2
to
b242031
Compare
LGTM |
I don't think it's breaking, it's a bug fix. We always intended for |
@@ -137,6 +137,18 @@ const cli = { | |||
|
|||
log.info("v" + require("../package.json").version); | |||
|
|||
} else if (currentOptions.printConfig) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens if I do this:
$ eslint --print-config foo.js bar.js
In our current implementation, we get a warning. If I'm reading this code correctly, the new version would print the config for foo.js and not warn at all about bar.js, which I think is misleading. We probably want to check that files.length
is zero, and if not, throw up the same warning we currently do.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I thought about that. You are right, the behavior has changed. So I can add that check back in. (I removed a unit test for that specific behavior. I guess I hadn't considered that use case important, oops.)
I'll add a check and I'll get that test back into tests/lib/cli.js. Sound good?
@eslint/eslint-tsc Just want to confirm, should this be regarded as a bug-fix and non-breaking, per @ilyavolodin's comment here? Thanks! |
LGTM |
@nzakas I've added the logic and test back in, though I changed the error message for clarity. Please let me know if further changes are needed. Thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
type: "Boolean", | ||
description: "Print the configuration to be used" | ||
type: "path::String", | ||
description: "Print the configuration which would be used for linting a given file (linting will not occur)" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm guessing this will cause the text to wrap when output on the console. I'm not sure this needs to be changed from the previous text, but if it does, then can you make it a bit shorter?
It does wrap, but prettily (I.e., first character of second line aligns On Sep 23, 2016 1:43 PM, "Nicholas C. Zakas" notifications@github.com
|
@nzakas Here's how my Personally I think this should work, but let me know if you want it shorter anyway. |
I still think it should be shorter. We have documentation for details, these should just be short phrases. |
@nzakas Could I get a suggestion of what you're getting at? (Note that there are other options which go onto two lines.) I'm not sure how to shorten what I've got without losing meaning. |
Optionator does nice line wrapping at all widths. That being said, you could rephrase it to something like:
|
@platinumazure I think you can just leave the message as it was before. I don't see a great need for changing it. |
64db3df
to
b109380
Compare
LGTM |
@nzakas I've changed the option description-- it's shorter, but I wanted to at least allude to the option argument. It fits on one line on my terminal (which is 80 characters wide). I've also reclassified this as a non-breaking bugfix per consensus on this issue. Please let me know if anything else needs to change. Also, please let me know if I still need to do anything to get this accepted? I think TSC can just accept if they like? (Nobody has objected to the idea yet, at any rate.) |
What is the purpose of this pull request? (put an "X" next to item)
[ ] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofixing to a rule
[ ] Add a CLI option
[ ] Add something to the core
[x] Other, please explain:
Changing behavior of a CLI option (--print-config).
Please check each item to ensure your pull request is ready:
What changes did you make? (Give an overview)
Since --print-config operates on one file, I've changed the option from being boolean-valued to being string-valued (in other words, the file for which user wants to print a config becomes an argument to the option itself).
This is technically a breaking change because this use is now broken:Consensus seems to be that this is not a breaking change, becauseeslint --print-config --other-options-here fileName.js
. In addition, it will no longer flag if too many files are passed in. However, the advantage of this is the optionator output for this option is improved and we get validation for free.--print-config --some-option fileName.js
was never really intended to work, it just happened to because of the implementation.Needed to update optionator to pick up a bugfix (otherwise, non-boolean options at the end of a command line were not validated properly).
Is there anything you'd like reviewers to focus on?
Nothing in particular.