Stylelint: no token fallback values (VideoPress, Search, Forms, Publicize, & Boost) - #50527
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! Boost plugin: No scheduled milestone found for this plugin. If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack. Search plugin: No scheduled milestone found for this plugin. If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack. Videopress plugin: No scheduled milestone found for this plugin. If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack. |
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. 🤷 |
|
FYI I still need to do a bit more testing but in theory this is ready :-) |
Strip hand-written --wpds-* fallbacks from Forms, Publicize, and Search styles now covered by the no-token-fallback-values stylelint override.
5b22b10 to
8cbbea8
Compare
Follow-up to #50110 which added linting for WPDS tokens but didn't enforce the "no fallbacks" rule yet.
At #50502 we started enforcing WP Build routes; this PR starts enforcing some of the bundles now using
@wordpress/theme/postcss-plugins/postcss-ds-token-fallbacksto inject fallbacks automatically at build time.Proposed changes
@wordpress/theme/postcss-plugins/postcss-ds-token-fallbacksvar(--wpds-*, …)fallbacks: all of them matched with canonical@wordpress/themevaluesBundles mostly stay the same
**Confirmed.** Before (`85920e3b10`) vs after (`8cbbea829d`) builds of search, publicize, videopress, forms, and boost are the same aside from WPDS fallback corrections (and the style content-hashes those change).Bundle identity
After normalizing
var(--wpds-*, …)fallbacks (and thedata-wp-hash/registerStylehashes driven by that CSS), all 240 comparable CSS/JS files match. Token sequences and counts are unchanged.Fallback corrections (manual → theme)
Only forms and publicize changed. Search/VideoPress/Boost had no mismatched manual fallbacks in these builds.
--wpds-color-background-surface-neutral-weak#e7e7e7#f4f4f4--wpds-color-stroke-surface-neutralvar(--jp-forms-border-color, #e0e0e0)#dbdbdb--wpds-color-stroke-surface-neutral-weak#e4e4e4#f0f0f0--wpds-color-foreground-content-neutralvar(--jp-gray-80)/#50575e#1e1e1e--wpds-color-foreground-content-neutral-weak#757575#707070--wpds-color-foreground-content-error#d63638#470000--wpds-color-stroke-focus#3858e9var(--wp-admin-theme-color, #3858e9)--wpds-border-width-focus2pxvar(--wp-admin-border-width-focus, 2px)--wpds-motion-duration-md0.15s200ms--wpds-motion-easing-balancedease-outcubic-bezier(0.4, 0, 0.2, 1)Related product discussion/links
Does this pull request change what data or activity we track or use?
Testing instructions