Skip to content
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

Merged
merged 1 commit into from Jan 19, 2017
Merged

Conversation

alexgibson
Copy link
Member

@alexgibson alexgibson commented Jan 4, 2017

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

@alexgibson
Copy link
Member Author

Would very much like input from @craigcook (and also @jpetto if he has any free mozorg time)

@alexgibson
Copy link
Member Author

alexgibson commented Jan 5, 2017

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.

@alexgibson alexgibson force-pushed the stylelint branch 4 times, most recently from 7f16b25 to 2f46e96 Compare January 5, 2017 15:47
"comment-no-empty": true,
"max-nesting-depth": [5, { "severity": "warning" }],
"no-duplicate-selectors": [true, { "severity": "warning" }],
"no-invalid-double-slash-comments": true,
Copy link
Contributor

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.

Copy link
Member Author

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...

Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Member Author

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,
Copy link
Contributor

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. 😁

Copy link
Member Author

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,
Copy link
Contributor

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...

Copy link
Member Author

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...

Copy link
Member

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 !importants in the search stuff because Google) but hopefully that won't get out of hand.

Copy link
Member Author

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.

Copy link
Member

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.

Copy link
Member Author

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']);
Copy link
Contributor

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?

Copy link
Member Author

@alexgibson alexgibson Jan 5, 2017

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 👍

Copy link
Member Author

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 👍

@alexgibson alexgibson force-pushed the stylelint branch 7 times, most recently from 160664c to fd8671e Compare January 6, 2017 15:34
@jpetto
Copy link
Contributor

jpetto commented Jan 6, 2017

This is looking really good to me. Do we just need to fix all current linter errors before it's ready to merge?

@alexgibson
Copy link
Member Author

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"?

@jpetto
Copy link
Contributor

jpetto commented Jan 6, 2017

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!

@alexgibson alexgibson force-pushed the stylelint branch 6 times, most recently from 9d8ec6a to 7f8ad03 Compare January 10, 2017 11:38
@alexgibson
Copy link
Member Author

alexgibson commented Jan 10, 2017

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 👍

@alexgibson alexgibson force-pushed the stylelint branch 2 times, most recently from 6673853 to 33429aa Compare January 11, 2017 09:15
@alexgibson
Copy link
Member Author

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;
Copy link
Member

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...

Copy link
Member Author

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

Copy link
Member

@craigcook craigcook left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

r+! 🚀

@craigcook craigcook merged commit fbeae48 into mozilla:master Jan 19, 2017
@alexgibson alexgibson deleted the stylelint branch January 19, 2017 16:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants