-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Stylelint update #968
Stylelint update #968
Conversation
This pull request is being automatically deployed with ZEIT Now (learn more). 🔍 Inspect: https://zeit.co/primer/primer-css/pc0873qne |
@@ -87,7 +95,9 @@ | |||
// FIXME deprecate 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.
This might be a good candidate for a TODO@14.0.0
comment (see: #946).
src/buttons/button.scss
Outdated
@@ -15,7 +17,9 @@ | |||
background-repeat: repeat-x; | |||
background-position: -1px -1px; | |||
background-size: 110% 110%; | |||
border: 1px solid transparentize($black, 0.8); | |||
// stylelint-disable-next-line primer/borders | |||
border: $border-width $border-style transparentize($black, 0.8); |
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 consistency, I think we should use rgba()
here rather than transparentize()
(which decreases the alpha channel by the provided amount):
border: $border-width $border-style transparentize($black, 0.8); | |
border: $border-width $border-style rgba($black, 0.2); |
Of course, at that point we might as well switch over to using $border-black-fade
/ $black-fade-15
, which has an alpha of 15%? 🤔 Here are 15%, 20%, and 30% for comparison:
RGBA | SCSS | Image |
---|---|---|
$border-black-fade |
rgba(27,31,35,0.15) |
|
rgba($black, .2) (current) |
rgba(27,31,35,0.20) |
|
$black-fade-30 |
rgba(27,31,35,0.30) |
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.
FYI @simurai I found all our transparent $black
values and dropped them in our spreadsheet to look at later. At the very least, I think we should standardize on using rgba($color, $alpha)
rather than transparentize($color, $alpha-offset)
.
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.
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.
At the very least, I think we should standardize on using
rgba($color, $alpha)
rather thantransparentize($color, $alpha-offset)
.
Yeah, I find rgba($black, 0.2)
much easier to read. Maybe because transparentize($black, 0.8)
requires you to do some math first. I guess the only time we would need transparentize()
is when we want to make a color that already is semi-transparent a little more transparent. But that's maybe a rare case we don't have to worry about.
syntax: 'scss', | ||
rules: { | ||
'scss/dollar-variable-default': [true, {ignore: 'local'}], |
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 rule enforces the inclusion of !default
in all of our global variables.
Here is a list of new tasks for #925 when we're ready to merge 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.
Looks good. 👍
Since this touches a lot of files... do you wanna go ahead and already merge it into release-14.0.0
? Then when making new changes we can branch off from release-14.0.0
instead of master
to avoid merge conflicts.
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.
🚢
Our new and improved stylelint config introduces some new rules, and these rules demand fealty! Here's my workflow for rectifying the new linting errors, one rule at a time:
stylelint.config.js
.npx stylelint-only <rule> -- --fix src
to autofix as many values as possiblenpx stylelint-disable <rule> -- src
to addstylelint-disable-next-line
comments above offending declarations.npx stylelint-only <rule> -- src
to see if there are any remaining violations, and fix those manually. (Most of these were because of extra lines being added after comments bystylelint-disable
).git add -p
, skip any changes that are undesirable (such ascolor: $tooltip-text-color
outside of tooltips), thengit checkout -- src
to throw out the changes we don't want.I've added stylelint-only and stylelint-disable as dev dependencies so that we can use them more readily for focused linting and/or refactors.
The other thing I've done here is added some new "functional" variables to cover common patterns:
$bg-white: $white
"fixes" 32 instances of `background-color: $white'$text-white: $white
fixes 24 instances ofcolor: $white
$text-black: $black
fixes a handful of instances ofcolor: $black
$border-white: $white
fixes a handful of border colors with$white
$border-color-button: rgba($black, 0.2)
replaces a bunch of static instances of button border colors.I've also added TODO deprecation comments (per #946) that state our intent to deprecate those variables in #925 (v14.0.0). I suppose we should add a new field to our deprecations data for variables too, huh?