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
Add --print-config
flag
#529
Conversation
cli-main.js
Outdated
if (options.stdin) { | ||
if (options.printConfig) { | ||
if (input.length > 0) { | ||
console.error('The `print-config` option must be used with exactly one file name'); |
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.
console.error('The `print-config` option must be used with exactly one file name'); | |
console.error('The `--print-config` flag must be used with exactly one filename'); |
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.
This message is confusing as it makes it sound like the user passed multiple filenames to --print-config
.
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.
That’s exactly the mistake this is intended to catch: xo --print-config x.js y.js
. (This is parsed as {flags: {printConfig: 'x.js'}, input: ['y.js']}
, but a user who writes that probably doesn’t know that.)
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Co-authored-by: teehemkay <tmk@exidia.com> Signed-off-by: Anders Kaseorg <andersk@mit.edu>
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.
Applied all changes and squashed them into the --print-config
commit. I also added three new commits to consistently apply these changes elsewhere in the existing code.
Looks good. Thank you 👍 |
I often find myself needing this option to figure out which rules XO is using. If I learn about a new ESLint rule, I want to be able to check whether XO already enables it or something similar; if I upgrade XO, I want to be able to check whether it disabled any rules I was relying on; I want to be able to check that I configured
overrides
correctly and that it’s applied in the order I expect; etc.This was largely based on #312 by @teehemkay.