Components: Add lint rules for theme color CSS var usage #59022
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mirka
added
[Type] Code Quality
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
Size Change: -3 B (0%) Total Size: 1.71 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in 221fcaa. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/7918586662
|
tyxla
approved these changes
Feb 15, 2024
.eslintrc.js
Outdated
Comment on lines
375
to
386
| { | ||
| selector: | ||
| 'Literal[value=/var.+--wp-components-color-/]', // allow overriding definitions, but not access with var() | ||
| message: | ||
| 'To ensure proper fallbacks, --wp-components-color-* variables should not be used directly. Use variables from the COLORS object in packages/components/src/utils/colors-values.js instead.', | ||
| }, | ||
| { | ||
| selector: | ||
| 'TemplateElement[value.cooked=/var.+--wp-components-color-/]', // allow overriding definitions, but not access with var() | ||
| message: | ||
| 'To ensure proper fallbacks, --wp-components-color-* variables should not be used directly. Use variables from the COLORS object in packages/components/src/utils/colors-values.js instead.', | ||
| }, |
There was a problem hiding this comment.
Don't know if it makes things more or less understandable, but you could squash these rules with a :matches...
Suggested change
| { | |
| selector: | |
| 'Literal[value=/var.+--wp-components-color-/]', // allow overriding definitions, but not access with var() | |
| message: | |
| 'To ensure proper fallbacks, --wp-components-color-* variables should not be used directly. Use variables from the COLORS object in packages/components/src/utils/colors-values.js instead.', | |
| }, | |
| { | |
| selector: | |
| 'TemplateElement[value.cooked=/var.+--wp-components-color-/]', // allow overriding definitions, but not access with var() | |
| message: | |
| 'To ensure proper fallbacks, --wp-components-color-* variables should not be used directly. Use variables from the COLORS object in packages/components/src/utils/colors-values.js instead.', | |
| }, | |
| { | |
| selector: | |
| // allow overriding definitions, but not access with var() | |
| ':matches(Literal[value=/var.+--wp-components-color-/],TemplateElement[value.cooked=/var.+--wp-components-color-/])', | |
| message: | |
| 'To ensure proper fallbacks, --wp-components-color-* variables should not be used directly. Use variables from the COLORS object in packages/components/src/utils/colors-values.js instead.', | |
| }, |
Also, is it worth being a bit more specific with the RegExp? It currently matches anything that starts with var and ends with --wp-components-color-, so (while highly unlikely to happen, I'll grant you!) could hit some false positives:
// ⛔️ /var.+--wp-components-color-/
const myCss = 'color: var(--wp-components-color-foreground, #FFF);'
// Matches ^------------------------^
const myCss = 'color: var(--anything, #000); --wp-components-color-background: #FFF;'
// Matches ^-------------------------------------------^
// ✅ /var\s*\(\s*--wp-components-color-/
const myCss = 'color: var(--wp-components-color-foreground, #FFF);'
// Matches ^------------------------^
const myCss = 'color: var(--anything, #000); --wp-components-color-background: #FFF;'
// No matchThere was a problem hiding this comment.
you could squash these rules with a
:matches
Ooh, TIL! That looks cleaner to me too, thanks.
Also, is it worth being a bit more specific with the RegExp?
I actually wanted to add the parenthesis too, but I couldn't figure out how to do the escaping without Prettier complaining. Turns out I just needed a double backslash. Done 👍
aristath
added a commit
that referenced
this pull request
Feb 16, 2024
* trunk: (78 commits) Components: Use `Element.scrollIntoView()` instead of `dom-scroll-into-view` (#59085) DataViews: Correctly display featured image that don't have image sizes (#59111) Elements: Fix block instance element styles for links applying to buttons (#59114) Allow editing of image block alt and title attributes in content only mode (#58998) Add toggle for grid types and stabilise Grid block variation. (#59051) Global Styles: fix console error in block preview (#59112) Navigation: Avoid using embedded records from fallback API (#59076) Refactor responsive logic for grid column spans. (#59057) Editor: Unify Mode Switcher component between post and site editor (#59100) Move StopEditingAsBlocksOnOutsideSelect to Root (#58412) Fix logic error in #58951 (#59101) Block-editor: Auto-register block commands (#59079) Fix small typo in rich text reference guide (#59089) Components: Add lint rules for theme color CSS var usage (#59022) Enter editing mode via Enter or Spacebar (#58795) Updating Storybook to v7.6.15 (latest) (#59074) CustomSelectControl (v1 & v2): Fix errors in unit test setup (#59038) Add stylelint rule to prevent theme CSS vars outside of wp-components (#59020) ColorPicker: Style without accessing InputControl internals (#59069) Pattern block: batch replacing actions (#59075) ...
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Part of #44116
Follow-up to #58098
What?
Adds stylelint and eslint rules to prevent direct usage of
wp-components-color-*CSS variables in the components package.Why?
To ensure proper fallback values and to keep the code DRY.
How?
Although we are restricting variable access through
var(), at the moment I would still like to allow overriding definitions (--wp-components-color-foo: #000). There are legitimate use cases for it, and for now it's helpful to understand what those needs are.Testing Instructions
npm run lint:js. The violations should be caught.npm run lint:css. The linter should pass.