CORE-2737: Use the published ui-components CSS colour audit in REX

[OpenStaxClaude]

Second half of converging the two CSS colour audits, on top of CORE-2736.

Jira: https://openstax.atlassian.net/browse/CORE-2737

Based on CORE-2731-global-css-theme-tokens (#3133), which is where the REX copy of the engine lives. Review that first; the diff here is only the deduplication.

Stacking

This needs two parents, and they are independent of each other — a diamond rather than a chain:

• CORE-2731: Generate a global CSS token file from the theme #3133 (CORE-2731) for code: this PR deletes the engine copy that one adds.
• CORE-2853: upgrade node 14 -> 22 #3138 (CORE-2853, node 22) for environment: the ui-components bump will not yarn install on node 14.

2731 and 3138 share only package.json, in unrelated parts of it, and each is green without the other. So the suggestion is to land #3138 on main on its own, then rebase 2731 onto main — it picks up node 22 for free — and leave this PR on 2731 where it already sits. That gets both parents with nothing re-targeted. Stacking 3138 on 2731 would instead hold an already-green EOL-runtime upgrade behind a CSS refactor still in review.

Note that stacking alone will not make this PR green: the module fix in item 2 below is the binding constraint.

What this does

src/test/cssColors.ts goes from 587 lines to 181. The parsing engine — NAMED_COLORS, stripNoise, declarations, takesColor, describeColor, findColors, stylesheetColors, colorKey, opaqueKey — is imported from @openstax/ui-components/theme/cssColors rather than declared. What stays is the policy half, which is genuinely REX's: themeColorIndex over REX's nested theme, stylesheetFiles with its two exclusions, KNOWN_OFF_PALETTE, occurrence, colorViolations, and tokenChoices.

The engine's spec cases went to ui-components with the engine, so cssColors.spec.ts keeps only themeColorIndex and tokenChoices. Keeping a second copy of the assertions would drift the way the second copy of the code did.

theme.spec.ts now takes describeColor and stripNoise straight from the package instead of re-exporting them through cssColors.ts.

The load-bearing check

theme.baseline.json regenerates byte-identically against the imported engine — same md5, empty git diff. That is what shows the swap is behaviour-preserving rather than merely compiling.

It was not a foregone conclusion: the published engine had since added device-cmyk() to COLOR_FUNCTIONS and scrollbar to COLOR_SHORTHANDS, put a dotall flag on the rgba() grammar, and switched colorKey/opaqueKey from raw channels to hex. None of it moves a baseline line — REX's stylesheets contain none of those constructs, and the key format change is invisible because themeColorIndex and its lookups share the function.

The deduplication is done. The dependency bump is where the work is.

Pinned at openstax/ui-components#test-core-2736-2, whose dist is complete (-1 force-added dist/esm only, so anything reaching the package through require resolved to nothing).

Three things stand between this and a green CI, none of them about CSS colours.

1. Sentry 10 needs node ≥ 18; REX pins 14.15.4

ui-components 1.23.x depends on @sentry/react@^10.60.0. All CI jobs die in yarn install before anything compiles. Filed as CORE-2853 (node upgrade), where the investigation lives: the only real obstacle is webpack 4's md4 hashing under OpenSSL 3, fixable with NODE_OPTIONS=--openssl-legacy-provider; everything else — unit, lint, sourcemap, prerender, browser suites — already passes on node 18.

Roy asked whether an earlier Sentry could avoid the bump. Tested on a real node 14.15.4: yes, with a ui-components change. Eleven of the twelve Sentry APIs ui-components uses exist in 7.120.4 (7.119+ backported the functional-integration API). The twelfth, Sentry.captureReactException, is v9+. With resolutions: {"@sentry/react": "^7.120.3"}, node 14 gives yarn install exit 0 with no --ignore-engines, yarn build exit 0, 242/242 suites and 1942/1942 tests at 100% coverage, and a byte-identical baseline. Engine floors for reference: v7 >=8, v8 >=14.18 (REX misses by a patch release), v9/v10 >=18.

2. ⚠️ ui-components' module field points at a file that does not exist — and it costs 3 MB

"module": "index.js", with no index.js at the package root; it only resolves through the exports map. Webpack 4 (CRA 4) does not read exports, so it falls back to main and bundles dist/cjs. CommonJS means no tree-shaking:

build	chunk 519
main today	2.8 MB
this branch as it stands	5.4 MB — over workbox's 5 MB precache limit, which under CI=true is a hard build failure
with "module": "./dist/esm/index.js"	2.4 MB, smaller than main

A regression, not an original sin: 1e4b31136 (#116) introduced the split with "./dist/esm/index.js"; 7ac2a8a57 (#118) changed it to "index.js". Invisible to every consumer whose bundler reads exports.

Fix module only — types must stay "index.d.ts", because typesVersions rewrites it into dist/esm/ and a full path there gets double-prefixed.

3. The two interact, and that is the interesting part

Fix the packaging so webpack takes the ESM entry, and the Sentry 7 pin stops being silently survivable:

./node_modules/@openstax/ui-components/dist/esm/components/ErrorBoundary.js
Attempted import error: 'captureReactException' is not exported from '@sentry/react'

The pin only "works" today because the broken module field forces the CommonJS path, where a missing export is invisible until it is called — which is when an error boundary catches, i.e. exactly when you least want a TypeError. Two bugs cancelling into a passing build. REX does not use ui-components' ErrorBoundary (it has its own), so the dead code is harmless here, but that is luck rather than design.

Patching that one call to Sentry.captureException locally, both fixes together give a clean node 14 build at 2.4 MB with everything else still green.

What this needs

1. "module": "./dist/esm/index.js" in ui-components. Worth doing regardless of how anything else lands — straight regression, 3 MB of bundle.
2. A decision on Sentry: either ui-components drops captureReactException and widens @sentry/react (ideally to a peerDependency, so no resolutions entry is needed here), or REX does CORE-2853 first. The former only defers CORE-2853 — node 14 has been EOL since April 2023.
3. The screenshot suite, once one of those paths is chosen.

🤖 Generated with Claude Code

[RoyEJohnson]

Try building using tag test-core-2736-1

[OpenStaxClaude]

Heads-up: the base branch moved under this one. #3133 has been split in two at Roy's request, so src/test/cssColors.ts is now the parser alone (in #3142, against main) and everything theme-aware — themeColorIndex, KNOWN_OFF_PALETTE, stylesheetFiles, occurrence, colorViolations — lives in src/test/themeColors.ts on this branch's base.

That is the boundary this PR needed anyway: swapping in the published engine is now "delete src/test/cssColors.ts and re-point themeColors.ts and cssColors.spec.ts at @openstax/ui-components", with no theme-aware code to disentangle first. Expect a conflict on the next base merge; the resolution is to keep the base's split and drop this branch's edits to the REX-specific half.

Still a draft and still blocked by CORE-2736 either way.