Forms: forward-compatible WPDS color token fallbacks for @wordpress/theme 0.16 - #50082
Forms: forward-compatible WPDS color token fallbacks for @wordpress/theme 0.16#50082CGastrell wants to merge 2 commits into
Conversation
|
Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.
Interested in more tips and information?
|
|
Thank you for your PR! When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:
This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖 Follow this PR Review Process:
If you have questions about anything, reach out in #jetpack-developers for guidance! |
github-actions
Bot
added
the
[Status] Needs Author Reply
CGastrell
added
[Status] Needs Review
Code Coverage SummaryThis PR did not change code coverage! That could be good or bad, depending on the situation. Everything covered before, and still is? Great! Nothing was covered before? Not so great. 🤷 |
…heme 0.16 @wordpress/theme 0.16 renames the color design tokens (bg- -> background-, fg- -> foreground-) and drops the old names entirely. The Forms dashboard SCSS references the old names, so once theme 0.16 lands those vars go undefined and theming falls back to hardcoded hex. Reference the new token names first, with the existing name (and literal fallback) as the inner fallback, so theming is correct on both 0.15.1 (current trunk) and 0.16. Computed values are byte-identical on trunk. Stroke tokens are unchanged in 0.16 and left as-is. Decouples the Forms slice from the bundled-monorepo bump; no dependency on that PR in either direction. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…0.16 transition The fallback-chained color tokens reference both the 0.16 names and the current 0.15 names on the same line. The DS-token linter validates against a single installed @wordpress/theme vocabulary (via @wordpress/stylelint-config), so it flags whichever half isn't in the current vocabulary. Scope-disable the rule for projects/packages/forms/src/dashboard/** until the bundled monorepo bump (theme 0.16 + stylelint-config 23.41) lands; the override and the old-name fallbacks are removed together afterwards. Rule stays active everywhere else. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
b39fa61 to
984d7cf
Compare
| Significance: patch | ||
| Type: changed | ||
|
|
||
| Forms dashboard: reference the new WPDS color token names (--wpds-color-background-*/--wpds-color-foreground-*) with a fallback to the current names, so theming keeps working both before and after the @wordpress/theme 0.16 token rename. |
There was a problem hiding this comment.
Seems kind of verbose for end users. What do you think of something like this instead?
| Forms dashboard: reference the new WPDS color token names (--wpds-color-background-*/--wpds-color-foreground-*) with a fallback to the current names, so theming keeps working both before and after the @wordpress/theme 0.16 token rename. | |
| Forms dashboard: Improve compatibility with latest Gutenberg theming library. |
| */ | ||
| const config = { | ||
| extends: 'jetpack-js-tools/stylelint.config.base.mjs', | ||
| overrides: [ |
There was a problem hiding this comment.
I wonder if it would be better to put this into a projects/packages/forms/stylelint.config.mjs file instead of the root.
I suppose, if it's really temporary, it doesn't matter much. Don't forget to clean this up though!
|
Superseded by the full-repo token sweep. Per the discussion in jetpack-developers, the WPDS color token rename has to happen atomically with the bundled |
github-actions
Bot
removed
the
[Status] Needs Review
2 participants
Proposed changes
The Forms dashboard SCSS references the WPDS color tokens by their pre-0.16 names (
--wpds-color-bg-*/--wpds-color-fg-*).@wordpress/theme0.16 renames these (bg-→background-,fg-→foreground-) and drops the old names entirely (WordPress/gutenberg#79098). So once the bundled@wordpress/*monorepo update (#49272) lands theme 0.16, these custom properties go undefined and the dashboard theming silently falls back to its hardcoded hex values (losing themed/dark surfaces).This wraps each of the 15 references (6 dashboard SCSS files) to try the new name first, with the old name (and existing literal fallback) as the inner fallback:
@wordpress/theme0.15.1 and 0.16 — on trunk the new name is undefined so it resolves to the inner fallback, i.e. the exact original expression. Computed values are byte-identical today; there is no visual change on trunk. It simply keeps theming working after the bump.--wpds-color-stroke-*tokens are unchanged in 0.16, so they are left as-is.Related product discussion/links
Does this pull request change what data or activity we track or use?
No.
Testing instructions
@wordpress/theme0.15.1): open the Forms admin — Responses/Inbox dashboard — and confirm it renders identically to before (surfaces, headers, tab colors, comment cards). The old token names still resolve through the fallback, so nothing should look different.@wordpress/theme0.16 bump applied (e.g. the Update Bundled @wordpress/* monorepo #49272 branch), confirm the dashboard still themes correctly — now via the new--wpds-color-background-*/--wpds-color-foreground-*names — instead of dropping to hardcoded hex.pnpm jetpack build formscompiles cleanly.