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 Stylelint to gulp and CI #4567
Conversation
Would very much like input from @craigcook (and also @jpetto if he has any free mozorg time) |
Ok I think I've made a decent run through of a basic rules list. Certain things (mostly stylistic) are only classed as warnings, but it's all up for discussion. I'd like to try and formalize some form of consensus on what we think is sensible, before moving on to actually fixing any linting errors or adding exceptions. |
7f16b25
to
2f46e96
Compare
"comment-no-empty": true, | ||
"max-nesting-depth": [5, { "severity": "warning" }], | ||
"no-duplicate-selectors": [true, { "severity": "warning" }], | ||
"no-invalid-double-slash-comments": true, |
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.
Based on the lack of related errors when running locally, this appears to be smart enough to ignore double slash comments in .less
and .scss
files.
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 this only applies to CSS files, where it can cause issues. It ignores both Sass and Less comments, so maybe this is actually redundant 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.
Are we linting post-processed .css files as well, or only the pre-processed source?
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.
Are we linting post-processed .css files as well, or only the pre-processed source?
No, this would probably be a next step after this.
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 actually going to leave this rule in, as we do have some regular .css
files in /media
.
"keyframe-declaration-no-important": true, | ||
"declaration-no-important": true, | ||
"declaration-block-no-duplicate-properties": [true, { "severity": "warning" }], | ||
"declaration-block-no-ignored-properties": true, |
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.
Wondering how this will play with workarounds for quirks in IE 9. Might illuminate some phony voodoo though. 😁
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, will delve into the errors it's throwing currently - might need to drop this to a warning perhaps, and add exceptions for where it's required.
"property-case": "lower", | ||
"property-no-unknown": true, | ||
"keyframe-declaration-no-important": true, | ||
"declaration-no-important": true, |
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 really hope we can do away with !important
, but I have a hunch we'll need it, at least for a while...
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.
For now I plan to make exceptions for it in the download button styles, but let it throw an error everywhere else...
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.
We might sometimes have to update the exceptions list (there are several !important
s in the search stuff because Google) but hopefully that won't get out of hand.
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.
Exceptions are added directly around the effected areas of CSS, so adding one for the Google search thing is pretty easy. I'd prefer to do this and try and keep the rule a strict "no" by default.
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, that makes sense. I was envisioning some kind of separate "ignore" list we'd have to maintain, which sounds like a bad idea. But just some special comment at the point of instance is much nicer. So in that case I also vote for keeping this as a full-blown error; !important
should only be allowed under very special circumstances.
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've added some overrides to usages of !important
where it's probably need it, so it's easier to see some practical examples.
gulp.task('static:clean', () => { | ||
return del(['static/**', '!static', '!static/.gitignore']); | ||
}); | ||
|
||
gulp.task('default', () => { | ||
gulp.start('media:watch'); | ||
gulp.watch(lintPaths, ['js:lint']); | ||
gulp.watch(lintPathsJS, ['js:lint']); |
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.
Should we add the CSS linter to the default task? Or is it too slow/cumbersome?
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.
It currently takes around 10 seconds to lint everything, which is kinda a long time... could still add it though? Will see how it plays out 👍
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 changed our default gulp task to lint both CSS and JS files, but for changed files only instead of the whole folders. This speeds things up considerably 👍
160664c
to
fd8671e
Compare
This is looking really good to me. Do we just need to fix all current linter errors before it's ready to merge? |
I'm thinking I'll fix all the errors, and maybe a bunch of easy warnings. Then we could leave the rest up as "good-first-bugs"? |
Sounds like a plan! |
9d8ec6a
to
7f8ad03
Compare
OK, i think i have this in a pretty good place. Once #4571 is merged I'll rebase and CircleCI should pass. Once this PR is merged, I'll file a tracking bug so contributors can help fix the linting warnings 👍 |
6673853
to
33429aa
Compare
Ok this is passing in CircleCI 🎈 I think this is now ready for code review. |
@@ -186,11 +185,6 @@ html[dir="rtl"] #nav-main .submenu { | |||
padding: 0; | |||
} | |||
|
|||
.js #nav-main li .submenu { | |||
xleft: 80px; | |||
xtop: auto; |
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.
Wow, where did this even come from? Did I do that? Probably been here for years...
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.
No idea - it was so mysterious I even searched in case there was some random proprietary thing I didn't know existed. Came up blank
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.
r+! 🚀
Taking a look at adding Stylelint to our gulp/CI. The full list of rules that can be applied is here: http://stylelint.io/user-guide/rules/
Right now this is just linting our Sass files, but I'll take a look to see if it can do the Less files too. I'm trying to avoid purely stylistic things, but if there are things that we would normally pick out in code review anyway we should probably add them.
Like ESLint, you can make allowances for certain rules on a case by case basis using CSS comments: http://stylelint.io/user-guide/configuration/#turning-rules-off-from-within-your-css
We can also make certain rules only report as warnings, so not to break a build: http://stylelint.io/user-guide/configuration/#severities-error--warning