Make createCompatConfig theme mappings safe to spread when a namespace returns a string

[ibnlanre]

When building the legacy config compat layer, namespace mappings like fontSize → text, boxShadow → shadow, animation → animate, etc. spread the result of theme(namespace, {}) directly:

...(theme('text', {}) ?? {})

Some of these namespaces can return a string (e.g. theme('text', {}) → '1rem'). Spreading a string produces char-indexed keys ({ '0': '1', '1': 'r', ... }) instead of a { DEFAULT: ... } entry, silently corrupting the compat config output.

This PR adds a small spreadTheme helper that normalizes the return value before spreading:

• string → { DEFAULT: value }
• plain object → { ...value }
• anything else → {}

and updates all namespace mappings to use it. Includes unit tests for the helper plus integration tests for the affected namespaces and the string-return regression cases.

[greptile-apps]

Confidence Score: 5/5

The PR appears safe to merge, with no actionable changed-code defects identified.

The helper preserves existing object mappings, correctly converts string-valued namespaces into DEFAULT entries, and the added tests cover the affected compatibility paths.

_{Reviews (1): Last reviewed commit: "Make `createCompatConfig` theme mappings..." | Re-trigger Greptile}

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 53f3c721-c003-4689-86f5-dd0e70aef5e3

📥 Commits

Reviewing files that changed from the base of the PR and between 46df7ee and 08da7ad.

📒 Files selected for processing (2)

• packages/tailwindcss/src/compat/config/create-compat-config.test.ts
• packages/tailwindcss/src/compat/config/create-compat-config.ts

---

Walkthrough

The change adds the exported spreadTheme helper. The helper wraps string values under DEFAULT, copies objects, and returns an empty object for arrays and unsupported values. Compatibility mappings for multiple theme namespaces and container max-width resolution now use this helper. Tests cover normalization behavior, namespace mappings, derived max widths, and default transition values.

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely describes the main change: making createCompatConfig theme mappings safe for string namespace values.
Description check	✅ Passed	The description accurately explains the string-spreading issue, the spreadTheme fix, affected mappings, and test coverage.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[RobinMalfait]

What's a situation/use case where you ran into this kind of issue?

[ibnlanre]

What's a situation/use case where you ran into this kind of issue?

I ran into this while working on Jumi, a Tailwind CSS v4 animation plugin I maintain.

I was resolving a project's theme through the compat layer so Jumi could read the animation values, and for certain themes the output just looked… wrong. A value that should come back as { DEFAULT: 'spin 1s linear infinite' } was instead coming back as { '0': 's', '1': 'p', '2': 'i', … }. When a namespace only defines its DEFAULT token (e.g. @theme { --animate: … } with no --animate-* variants), theme('animate', {}) returns a plain string, and spreading a string gives you character-indexed keys instead of { DEFAULT: … }.

What made me think this could've gone unnoticed for a while is that it's completely silent. The config still resolves, so one would only notice when something (typically, a plugin) actually reads those theme values. I also had several cases of arbitrary class values returning as just "e" because of this bug.