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
New: Add eslint:all
option (fixes #6240)
#6248
Conversation
Thanks for the pull request, @mockdeep! 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.) |
By analyzing the blame information on this pull request, we identified @alberto, @nzakas and @gyandeeps to be potential reviewers |
LGTM |
eslint:all
option (#6240)eslint:all
option (refs #6240)
I was looking for a good place to update the docs around this, but wasn't sure if any of the docs in the repo made sense. Seems like more of an advanced configuration thing. |
@@ -0,0 +1,13 @@ | |||
"use strict"; |
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.
Please follow the same format as other files: http://eslint.org/docs/developer-guide/code-conventions#file-format
@mockdeep can you update your commit message to say "fixes" instead of "refs"? @pedrottimark any idea where docs for this should go? |
var fs = require("fs"); | ||
var path = require("path"); | ||
|
||
var ruleFiles = fs.readdirSync(path.resolve(__dirname, "../lib/rules")); |
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 think we should lazyload this since not everyone is going to be using eslint:all
but they would still endup paying the price for a whole directory scan at load time.
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.
Doesn't this only get loaded if they have it configured?
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.
ah. sorry I dint see the require on the other end.
LGTM |
eslint:all
option (refs #6240)eslint:all
option (fixes #6240)
added format comments and updated commit message |
I think it makes sense to mention this on the rules page underneath the section that goes over |
@kaicataldo we could briefly mention it, but we also need a big warning about it's use, and I don't think jamming that at the top of the rules page makes sense. Ping @pedrottimark |
Sorry, my bad to overlook this one. Agree not on the rules index page.
|
Here is a rough draft for comment first priority about the place and structure: Extending Configuration Files If you want to extend a specific configuration file, you can use the
|
//------------------------------------------------------------------------------ | ||
|
||
var ruleFiles = fs.readdirSync(path.resolve(__dirname, "../lib/rules")); | ||
var enabledRules = lodash.reduce(ruleFiles, function(result, 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.
I'm a little curious about differences from ruleFiles.reduce(function(result, filename) {
.
Why lodash
is needed here?
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.
Oh, good call. I'll change that.
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.
Ha, I had some changes locally where I was trying to remove the lodash
dependency using Object.keys
. I had forgotten reduce
was available on arrays.
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.
Updated to remove lodash
dependency.
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.
Thank you! 👍
LGTM |
Thinking what description will say as much as possible in as few words as possible. @mockdeep Just thinking through the phrase “I want to be made aware of rule updates” do you mean when a new rule reports problems, then you read about it and decide one of the following:
What are your thoughts about the safety of using @nzakas I am reading and rereading your comments in #6240 and would be glad for guidance about anything you consider definitely must-say and any max or min number of sentences to say it? Do you think it is worth making an explicit contrast: which rules are recommended changes only at major versions, but which rules are in all can change at any minor version. Thinking about major versions somehow sent my mind back to the future: will deprecated rules still be included in all? |
@nzakas P.S. If you think that the content size target is more than a few sentences in a bullet point, what do you think about applying the new structure for rule options in Configuring ESLint: Extending Configuration Files is already a level-2 heading like Options EDIT: Provide a bulleted list summary of values for Put the examples and any extended description under level-3 headings as we do with options. |
Yep, that sounds reasonable, with the possibly addition of a fourth: "4. agree that the problems are problems, but fixing would be non-trivial or bloat the diff, so turn it off with a note to fix later"
I don't fully understand what you're saying in this bit. Are you saying that the rule change won't show up in the git history because it's not being added to a rule file? That's not a huge bother really as far as we're concerned. The commit message of the change should have enough detail to let people know where it came from. I generally have an eye towards small commits, so when upgrading if it's only a handful of changes I will go ahead and do them, but if there are a bunch I might actually disable the rule and then re-enable it on a followup commit to keep the history more clear. I will first typically run eslint without the |
@mockdeep Sorry I was’t so clear the first attempt. If you lint first without I’m thinking about how likely and serious a risk to people who are less careful and do-it-yourself, who might learn of Because I am not strong at devops, I can relate to recent cautions about risk of using “boilerplate” configurations with only shallow understanding of the options for the various tools. |
@pedrottimark Ah, I see. Well it seems like that would be less of a problem if you're simply upgrading, since you're aware of what you're up to and the changes are likely to be much smaller. But even on a new install if you enable |
@mockdeep Bearing in mind that the risk with either I'm not trying to torpedo the proposal-- we can certainly add warnings a-plenty in documentation and we can certainly encourage people to pin their ESLint versions when using |
Yes, agree that both are similar for new installation. Forgot to say that I am not arguing against the feature, but thinking about what information people need to know and where to put it so they find it. |
Makes sense. I'm all for having clear documentation to make sure expectations are clear. |
From my point t of view, we need to communicate:
|
Am working on a pull request with changes to Extending Configuation Files in configuring.md @nzakas Should it have commit tag Docs and ref this pull request? |
@pedrottimark should ref #6240 |
The code looks good, so I'm going to merge. We can work on the documentation next. |
You can use a home directory configuration or a config file in an ancestor
directory of all your products. However, best practice is probably too
create a new configuration file.
…On Jan 4, 2017 1:57 PM, "Spencer Sims" ***@***.***> wrote:
@nzakas <https://github.com/nzakas> , @mockdeep
<https://github.com/mockdeep> any idea on how to do this with the cli?
I'm trying to have the rules enabled in vim that I can use on any file
without having to specify a config file each time I want to work on a new
project.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#6248 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AARWejp4psDLTMTKdbl4wmeyD7lBtPKmks5rO_mUgaJpZM4ImIQM>
.
|
This adds a new option to allow a user to extend
eslint:all
in orderto enable all rules by default.