Components: Complete WPDS token migration for remaining borders#79003
Conversation
|
@Infinite-Null @himanshupathak95, Since you are working on the same issue, it would be better to consolidate it into one. |
Thanks @t-hamano for looking into this. @Infinite-Null mentioned their PR is focusing on |
|
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. |
|
Thanks for tackling this! There are more opportunities for refactor that we could tackle in this PR: the search here looks SCSS-only ( Remaining
|
|
I'd be tempted to handle |
|
Thanks for the detailed feedback @ciampo! I completely agree with the approach. I've gone ahead and applied these updates locally: Swapped the disabled interactive controls (button, form-toggle, radio-control) to use stroke-interactive-neutral-disabled. However, I hit a blocker with the pre-commit hooks when trying to push the Emotion .ts changes. Our ESLint strict configuration is rejecting the direct use of the WPDS tokens inside the styled-components template strings: How would you prefer to handle this within @wordpress/components? Should I just add an eslint-disable-next-line @wordpress/no-ds-tokens above these specific usages? |
@himanshupathak95 you're right, my bad. I forgot that, since we can't reliably add fallback values for the For now, we can simply add comments about each instance, something like |
himanshupathak95
force-pushed
the
upd/79001-components-wpds-border-colors
branch
from
19d5252 to
56e57e3
Compare
@himanshupathak95 just in case it was not clear, I'm proposing we add such We should also add a CHANGELOG entry under |
|
This PR might have started the Storybook failure in trunk. It started after this PR was merged - https://github.com/WordPress/gutenberg/actions/workflows/storybook-check.yml?query=branch%3Atrunk |
|
@manzoorwanijk reverting here #79243 |
|
Looks like the error comes from the inline JS comments containing Separately, I'll look into improving the linter to check for code comments, too. |
|
Since it's affecting all new pull requests I'd personally opt to revert first and then unrevert with the focused fix. |
…ents
The esbuild design-token fallback plugin claims any JS/TS file whose source
text contains the `wpds` token prefix (a plain substring check, comments
included). Claiming the file replaces the Emotion transform, so styled
component selectors throw at runtime ("Component selectors can only be used
in conjunction with @emotion/babel-plugin"). #79003 introduced TODO comments
referencing the full token custom-property names in Emotion `.ts` files,
which broke the Storybook build on trunk.
Rephrase those comments (and pre-existing ones in dropdown-motion,
config-values, and use-modal-exit-animation) to name the WPDS tokens without
the CSS custom-property prefix, so the fallback plugin no longer claims these
files. The `no-ds-tokens` ESLint rule does not catch this because it only
inspects string literals and template elements, not comments.
…ents
The esbuild design-token fallback plugin claims any JS/TS file whose source
text contains the `wpds` token prefix (a plain substring check, comments
included). Claiming the file replaces the Emotion transform, so styled
component selectors throw at runtime ("Component selectors can only be used
in conjunction with @emotion/babel-plugin"). #79003 introduced TODO comments
referencing the full token custom-property names in Emotion `.ts` files,
which broke the Storybook build on trunk.
Rephrase those comments (and pre-existing ones in dropdown-motion,
config-values, and use-modal-exit-animation) to name the WPDS tokens without
the CSS custom-property prefix, so the fallback plugin no longer claims these
files. The `no-ds-tokens` ESLint rule does not catch this because it only
inspects string literals and template elements, not comments.
…ments (#79244) * Components: Re-land WPDS border token migration (#79003) * Components: Avoid full DS token property names in Emotion source comments The esbuild design-token fallback plugin claims any JS/TS file whose source text contains the `wpds` token prefix (a plain substring check, comments included). Claiming the file replaces the Emotion transform, so styled component selectors throw at runtime ("Component selectors can only be used in conjunction with @emotion/babel-plugin"). #79003 introduced TODO comments referencing the full token custom-property names in Emotion `.ts` files, which broke the Storybook build on trunk. Rephrase those comments (and pre-existing ones in dropdown-motion, config-values, and use-modal-exit-animation) to name the WPDS tokens without the CSS custom-property prefix, so the fallback plugin no longer claims these files. The `no-ds-tokens` ESLint rule does not catch this because it only inspects string literals and template elements, not comments. * Components: Update CHANGELOG PR reference to the re-land PR --- Co-authored-by: himanshupathak95 <abcd95@git.wordpress.org> Co-authored-by: ciampo <mciampini@git.wordpress.org> Co-authored-by: t-hamano <wildworks@git.wordpress.org> Co-authored-by: jameskoster <jameskoster@git.wordpress.org> Co-authored-by: aduth <aduth@git.wordpress.org>
6 participants
What?
Part of #79001
Updates the remaining instances of hardcoded
$gray-300and$components-color-gray-300borders and inset box-shadows across the@wordpress/componentspackage to use the WPDSstroke-surface-neutraltoken.Why?
This is a follow-up to #78397. While the initial PR updated the Site Editor chrome to inherit the user's admin color scheme, several components (Modal, Panel, Form Toggle, Button, Radio Control) still used hardcoded gray borders.
This change ensures these component borders consistently adapt to the active admin color scheme when rendered inside the Site Editor.
How?
Replaced the hardcoded SCSS color variables with the CSS variable
var(--wpds-color-stroke-surface-neutral).Testing Instructions
npm run wp-env startandnpm run build.wp-adminand change your user profile's Admin Color Scheme to a dark theme (e.g., Modern or Midnight).Screenshots
$gray-300)stroke-surface-neutral)