Implement ESLint with eslint-config-edx#75
Conversation
|
By analyzing the blame information on this pull request, we identified @andy-armstrong, @dsjen and @dan-f to be potential reviewers |
| var eslint = require('gulp-eslint'), | ||
| gulp = require('gulp'), | ||
| paths = { | ||
| lint: [ |
There was a problem hiding this comment.
Do we need both this and the .eslintignore? Maybe this can just be **/*.js and let the exceptions be handled in the ignore file.
|
@bjacobel It looks like you have a leftover call to the old jscs gulp task. |
| (function() { | ||
| 'use strict'; | ||
|
|
||
| var renameAsMarkdown, generateDocFor; |
There was a problem hiding this comment.
I guess the convention has been to declare variables in alphabetical order unless declarations get messed up.
There was a problem hiding this comment.
I don't see us following this convention anywhere very frequently. Is it something you feel strongly about starting to enforce? We can look into if there's an eslint rule for it.
There was a problem hiding this comment.
I wasn't aware of that convention. I tend to declare them in the order I'm going to use them.
There was a problem hiding this comment.
I tend to declare them in the order I'm going to use, too.
There was a problem hiding this comment.
I'm with @andy-armstrong and @alisan617, I declare them in the order used. Alphabetical could be complicated if var aardvark relies on var zoo.
224e69b to
01d10aa
Compare
| "css-loader": "~0.23.1", | ||
| "del": "~2.2.0", | ||
| "edx-pattern-library": "~0.12.5", | ||
| "eslint-config-edx": "bjacobel/eslint-config-edx#bjacobel/feedback", |
There was a problem hiding this comment.
Isn't this supposed to be edx/eslint-config-edx 0.0.1 ?
There was a problem hiding this comment.
The 0.0.1 that's on NPM right now was released last Friday so it's a little stale, but I'm going to release a 1.0.0 to NPM after edx/eslint-config-edx#1 merges and then this can be updated to point there.
a9c180c to
a4ed075
Compare
… - Gulp does this already)
a4ed075 to
d431511
Compare
d431511 to
9a20fa8
Compare
|
This has no more linter issues and is ready for review.
|
9a20fa8 to
d774f77
Compare
| } | ||
| } | ||
| withData = function(data, func) { | ||
| Object.keys(data).forEach(function(key) { |
There was a problem hiding this comment.
Note to reviewers: for (... in ...) is banned by Airbnb ESLint because a) it has performance issues in some browsers and b) it loops over all enumerable properties, not just array members and object keys (e.g., toString).
It also wasn't a particularly good choice here anyway, because data was an Object, not an Array. So I swapped it out for Object.keys.forEach.
PS: In ES6 we can use for (... of ...) to do what for (... in ...) looks like it does.
|
this coveralls build: 883 of 935 relevant lines covered So there's three less lines covered, and three less lines overall... according to Coveralls that's a build failure. Wat. |
|
Hi folks! Would love to get this merged in this week, if we can - that's when I said we'd be turning it on in my email to edx-code. @dsjen and @andy-armstrong have already done an initial review, mind giving final signoff if I've addressed all comments? @AlasdairSwan and @alisan617, would love to hear your feedback too. Haven't figured out a good way to address the coveralls failure yet. Wish there was something analogous to |
|
LGTM 👍 |
| @@ -0,0 +1,5 @@ | |||
| { | |||
| "rules": { | |||
| "no-console": "off" | |||
There was a problem hiding this comment.
@bjacobel I quite like this rule, forcing people to merge cleaner code. Is there a reason we would want console.log statements in the codebase? I would be fine keeping warn or error if it is needed but vote to get rid of debugging statements from the code.
There was a problem hiding this comment.
ESLint allows per-directory configs, so this only applies to scripts in the gulp folder. I decided to allow console in Gulp scripts because 1) console is always defined in Node [*] and 2) console.log is pretty common in our gulp scripts as a means of feedback.
[*]: one of the arguments in favor of having no-console enabled in our browser code is that console is not implemented in IE9 and below; in Node this shouldn't ever be a problem
There was a problem hiding this comment.
Cool, thanks for the explanation.
d774f77 to
e9f9f31
Compare
|
👍 |
2 similar comments
|
👍 |
|
👍 |
|
@bjacobel Awesome find with the sinon bug! Great coverage improvements too. |
Install ESLint, and adopt our new styleguide.
If you have comments about the ESLint rules that are responsible for suggesting these changes, you can make them here: edx/eslint-config-edx#1. The ruleset/styleguide is not released/finalized yet, but will be 1.0 soon, so hurry!eslint-config-edxis now 1.0 on NPMTesting Checklist
N/A
Non-testing Checklist
Post-review
Reviewers
If you've been tagged for review, please check your corresponding box once you've given the 👍.
We'll also automatically suggest reviewers for this PR based on the code it touches.