-
Notifications
You must be signed in to change notification settings - Fork 4.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
Components: Add stylelint rule for theme var regressions #58098
Changes from all commits
2877a67
6037480
0d7acea
1083948
1f3e75a
9fa84ec
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,23 @@ | ||
/** @type {import('stylelint').Config} */ | ||
module.exports = { | ||
extends: '../../.stylelintrc.json', | ||
rules: { | ||
'declaration-property-value-disallowed-list': [ | ||
{ | ||
'/.*/': '/--wp-admin-theme-/', | ||
}, | ||
{ | ||
message: | ||
'--wp-admin-theme-* variables do not support component theming. Use Sass variables from packages/components/src/utils/theme-variables.scss instead.', | ||
}, | ||
], | ||
}, | ||
overrides: [ | ||
{ | ||
files: [ './src/utils/theme-variables.scss' ], | ||
rules: { | ||
'declaration-property-value-disallowed-list': null, | ||
}, | ||
}, | ||
], | ||
}; |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -148,11 +148,6 @@ | |
padding: 0 $grid-unit-10 2px; | ||
} | ||
} | ||
.components-placeholder__learn-more { | ||
.components-external-link { | ||
color: var(--wp-admin-theme-color); | ||
} | ||
} | ||
Comment on lines
-151
to
-155
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
For reference, this style was correcting a style override in the editor writing flow where it was showing this "Learn more" link in the Embed block with the site content link color, rather than the editor UI color: There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Nice cleanup! |
||
} | ||
|
||
|
||
|
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.
What about
--wp-components-color-*
variables? We've been using them in CSS-in-JS-styled components, for example (where SASS variables are not an option)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.
Good question. We can address this separately and incrementally after #58097 is merged so we have variables built into the
COLORS
object. The linting considerations for--wp-components-color-*
are much more complicated than--wp-admin-theme-*
, so I'd like to think through that better. Fortunately it's very easy to notice when--wp-components-color-*
is used without fallbacks, so direct usage is unlikely to cause visual regressions, just a matter of code DRYness.Interestingly, I found usages of
--wp-components-color-*
indataviews
andedit-site
😅 I'll address that separately as well.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.
Makes sense.
For next steps, what we could do, at least at a high level, could be:
--wp-components-*
CSS variables (with a fallback) instead"--wp-components-*
CSS variables are always associated with a fallback value--wp-components-*
CSS variables altogetherWhat do you think?
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.
Ouch 😅 Yup, should definitely be addressed. Another confirmation that those linter rules could be beneficial!
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 there are no cases (at least in SCSS files) where
--wp-components-*
vars need to be used instead of the Sass vars (which already have the correct fallbacks built in), so it's likely better to enforce the Sass var usage.Outside the components package, there are possible use cases that are legitimate, but we aren't ready to commit to anything yet so a blanket restriction is probably the way to go for now. (And the existing usages don't seem necessary.)
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.
Agreed