Jetpack: resolve WPDS design tokens in legacy dashboard CSS

[CGastrell]

Related to #48160. Unblocks #48711.

Proposed changes

• Extend the legacy _inc/ Jetpack settings dashboard's postcss pipeline (projects/plugins/jetpack/tools/postcss.config.js) so the @csstools/postcss-global-data files list also loads @wordpress/theme/design-tokens.css alongside the existing @automattic/calypso-color-schemes/root-only/index.css.
• Add @wordpress/theme as a direct dependency of plugins/jetpack so require.resolve('@wordpress/theme/design-tokens.css') works deterministically regardless of pnpm hoisting changes (previously it was only available transitively via @wordpress/ui).

Why this matters / why postcss-global-data and not a JS import

The legacy _inc/ dashboard's postcss pipeline runs postcss-custom-properties with preserve: false. That plugin inlines var(--foo) calls at build time using a fixed list of "global data" sources — and strips any matching :root { --foo: value } declarations from the output. So importing @wordpress/theme/design-tokens.css from JS (the obvious "just load it at runtime" approach) doesn't work: the runtime :root { --wpds-*: ... } block gets stripped during postcss processing, and var(--wpds-*) calls in consumer SCSS fall back to whatever hex the author hand-wrote in the second argument to var(...).

By adding @wordpress/theme/design-tokens.css to postcss-global-data's files, the postcss pipeline gains the WPDS token values at build time. var(--wpds-color-fg-content-success-weak) now resolves to the actual WPDS hex (#008030), matching the long-standing precedent for @automattic/calypso-color-schemes.

This unblocks consumers like PR #48711 — they can use raw var(--wpds-*) in legacy dashboard SCSS without manually mirroring every token value into a hex fallback. The hex fallbacks added by #48711 remain valid as defensive coding for surfaces that haven't run through this postcss pipeline (or for builds where the dependency hasn't resolved yet).

Related product discussion/links

• Tracking issue: Jetpack UI Modernization #48160
• Motivating consumer PR: Componentry: migrate Status to @wordpress/ui Text in plugin consumers #48711

Does this pull request change what data or activity we track or use?

No.

Testing instructions

This change is build/config-only; verification is via postcss output.

1. pnpm install (so the new @wordpress/theme dep resolves).

2. pnpm jetpack build plugins/jetpack — should run cleanly through the build-client step (any pre-existing _social-logos.scss SCSS failure is unrelated to this PR).

3. Verify resolution against synthetic input:

   cd projects/plugins/jetpack && node -e '
   const postcss = require("postcss");
   const config = require("./tools/postcss.config.js")();
   const input = `.x { color: var(--wpds-color-fg-content-success-weak, #008030); background: var(--wpds-color-fg-content-error-weak, #d63638); }`;
   postcss(config.plugins).process(input, { from: undefined }).then(r => console.log(r.css));
   '

   Expected output: .x { color: #008030; background: #cc1818; } — note that background differs from the inline fallback (#d63638 vs #cc1818), proving the WPDS token value is being used, not the SCSS-author-provided fallback.

4. Real-world spot check in _inc/build/jetpack-ai-admin.css: line that uses var(--wpds-color-fg-content-neutral-weak, #50575e) (from _inc/client/ai/mcp/style.scss) now resolves to #707070 (the WPDS token value) instead of the inline fallback #50575e.

5. After Componentry: migrate Status to @wordpress/ui Text in plugin consumers #48711 lands, _inc/build/admin.css will inline the success/error/warning/info indicator colors in the Status / pro-status rule blocks. No surface-level visual change is expected (the fallbacks added by Componentry: migrate Status to @wordpress/ui Text in plugin consumers #48711 already produce the same hex), but the var-based source becomes load-bearing.

[github-actions]

Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.

• To test on WoA, go to the Plugins menu on a WoA dev site. Click on the "Upload" button and follow the upgrade flow to be able to upload, install, and activate the Jetpack Beta plugin. Once the plugin is active, go to Jetpack > Jetpack Beta, select your plugin (Jetpack or WordPress.com Site Helper), and enable the change/dashboard-load-design-tokens branch.
• To test on Simple, run the following command on your sandbox:

bin/jetpack-downloader test jetpack change/dashboard-load-design-tokens

bin/jetpack-downloader test jetpack-mu-wpcom-plugin change/dashboard-load-design-tokens

Interested in more tips and information?

• In your local development environment, use the jetpack rsync command to sync your changes to a WoA dev blog.
• Read more about our development workflow here: PCYsg-eg0-p2
• Figure out when your changes will be shipped to customers here: PCYsg-eg5-p2

[github-actions]

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

• ✅ Include a description of your PR changes.
  
• 🔴 Add a "[Status]" label (In Progress, Needs Review, ...).
  
• ✅ Add testing instructions.
  
• ✅ Specify whether this PR includes any changes to data or privacy.
  
• ✅ Add changelog entries to affected projects
  

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:

1. Ensure all required checks appearing at the bottom of this PR are passing.
2. Make sure to test your changes on all platforms that it applies to. You're responsible for the quality of the code you ship.
3. You can use GitHub's Reviewers functionality to request a review.
4. When it's reviewed and merged, you will be pinged in Slack to deploy the changes to WordPress.com simple once the build is done.

If you have questions about anything, reach out in #jetpack-developers for guidance!

[jp-launch-control]

Code Coverage Summary

This 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. 🤷

Full summary · PHP report · JS report