Search: remove calypso-color-schemes and postcss-custom-properties plugin

[simison]

Split out from the bigger WPDS fallback mechanism PR #50108 to simplify it.
Similar PR for VideoPress: #50121

Proposed changes

Prepares Search to better take advantage of modern core WPDS style tokens and simplifies the setup.

• Remove @automattic/calypso-color-schemes from Search package.

  • Migrated the one and only Calypso --color-* token used to colour studio Sass variable instead. The actual color and built CSS stays exactly the same before/after this PR.

• Remove postcss-custom-properties plugin:

  • With preselve: false setting, this was used to inline Calypso color token values directly in bundles (color: var( --color-foo ) would translate to color: #000) to provide better browser support at the time when var wasn't as widely supported; see Update @automattic/calypso-build to v 5.0 #13854 (comment)). Now that we use WPDS style tokens, we intentionally want to have var() preserved; that's how the design system works, and fallback value is there just for backwards/odd case when variable isn't available at runtime. That way e.g. color scheme changes apply across components.
  • With preselve: true setting in Search blocks this was used to add duplicate fallbacks inline (color: #000;color: var( --token, #000 );), but with enough browser support for var(), this isn't really needed in practice, and we'll save some bytes by stopping doing this.
    • Source: `color: var( --token, #000 );
    • Bundle: color: #000;color: var( --token, #000 );

• Adds a plugin to add WPDS token fallbacks at build-time: color: var( --wpds-color-background-surface-neutral ) → color: var( --wpds-color-background-surface-neutral, #fcfcfc ). In later PR I'll remove manually added fallbacks; they're prone to get outdated over time. See docs.

• Removes separate postcss.blocks.config.js and use the same postcss.config.js for everything now that configs were basically the same.

• Applies postcss.config.js config to Search Dashboard as well; previously no PostCSS processing was done for Dashboard. This is particularly important because we now use WPDS tokens there and we need those fallbacks applied.

AI-generated notes analysing bundles before/after

Comparison of **trunk** vs **this branch** (`1a8e5d94ff`) — production CSS across 48 files in `packages/search`.

---

1. Bundle size

Bundle group	Trunk	Branch	Delta
dashboard	146,896 B	149,962 B	+3,066 B
search-blocks	97,703 B	96,751 B	-952 B
customberg	114,014 B	114,174 B	+160 B
instant-search	82,598 B	82,598 B	0
inline-search	6,152 B	6,152 B	0
Total	447,363 B	449,637 B	+2,274 B (+0.5%)

Net: slightly larger. Dashboard PostCSS adds the most; search-blocks shrinks from removing duplicate fallback lines.

---

2. Token preservation in bundles (corrected counts)

Token family	Trunk	Branch	Delta	Where
--wpds-*	690	690	0	dashboard only
--wp--preset--color--*	54	54	0	search-blocks, inline-search
--jp-search-*	18	18	0	search-blocks
--wp--* (all)	78	78	0	mostly --wp--preset--color--* + --wp--style--*
--wp-admin-*	138	166	+28	customberg (bundled WP components CSS)
--color-* (Calypso)	0	0	0	none

var() usage:

Metric	Trunk	Branch	Delta
Total var()	988	996	+8
With inline fallback	74	432	+358
Without fallback	914	564	-350

Notable preservation changes:

• customberg: Branch keeps var(--wp-admin-theme-color) instead of inlining #3858e9 → +4 var() calls, +28 --wp-admin-* refs.
• dashboard: Same 904 var() refs, but branch runs postcss-ds-token-fallbacks (trunk had no PostCSS). All 188 --wpds-* var() per direction now have inline fallbacks (trunk: 9 with fallback, 179 bare per direction).
• search-blocks / inline-search: Token refs unchanged; authored --wp--preset--color--* chains preserved as-is.

---

3. Fallback values

Inline fallbacks — var(--token, fallback)

Bundle	Trunk	Branch	Notes
dashboard	22	380	+358 — postcss-ds-token-fallbacks now applied
search-blocks	52	52	Authored in source (--jp-search-* → --wp--preset--color--* chains)
Other bundles	0	0	—
Total	74	432

Branch dashboard examples:

• var(--wpds-border-width-xs,1px)
• var(--wpds-color-stroke-surface-neutral-weak,#e0e0e0)

Duplicate-line fallbacks — prop:literal;prop:var(...)

Bundle	Trunk	Branch
search-blocks	50	2
dashboard	2	2
Total	52	4

Trunk search-blocks (from postcss-custom-properties with preserve: true):

gap:1.5rem;gap:var(--wp--style--block-gap,1.5rem)

Branch equivalent:

gap:var(--wp--style--block-gap,1.5rem)

Remaining 4 “duplicates” on branch are not trunk-style build artifacts:

• Dashboard (2): authored color:#f0f0f0;color:var(--jp-black)
• search-blocks/results-sort (2): nested var() chains that look like duplicates in regex only

---

4. PostCSS pipeline difference

	Trunk	Branch
Config	Calypso postcss-custom-properties (+ separate postcss.blocks.config.js with preserve: true)	Unified postcss-ds-token-fallbacks + autoprefixer
Dashboard	No PostCSS	PostCSS enabled
Calypso dep	@automattic/calypso-color-schemes	Removed

---

Bottom line

• Size: +2.3 KiB total — dashboard gains ~3 KiB of WPDS inline fallbacks; search-blocks saves ~1 KiB by dropping duplicate fallback lines.
• Tokens: No Calypso --color-*. Real color tokens are --wp--preset--color--* (54 refs) in blocks/inline-search, --wpds-* (690 refs) in dashboard, --jp-search-* (18 refs) in blocks.
• Fallback strategy: Branch shifts from mixed authored inline + build-time duplicate lines → consistent inline fallbacks via WPDS PostCSS on dashboard, with cleaner single-declaration output in search-blocks.

Related product discussion/links

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

Testing instructions

• Smoke test Search UIs (blocks, frontend, dashboards)

[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!

---

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.

[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 update/search-remove-calypso-color-schemes branch.
• To test on Simple, run the following command on your sandbox:

bin/jetpack-downloader test jetpack update/search-remove-calypso-color-schemes

bin/jetpack-downloader test jetpack-mu-wpcom-plugin update/search-remove-calypso-color-schemes

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

[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