Release request: 3.0.8 — #351 (bg-black/NN → #NaNNaNNaN) merged but unreleased

[Liroo]

#317 was fixed in main by #351, but the fix hasn't been released yet — 3.0.7 (published 2026-04-09) is still latest on npm, so bg-black/50 still silently produces no background for anyone on nativewind@5.0.0-preview.4 + Tailwind v4. Opening this separately since #317 is closed.

Any chance of cutting a 3.0.8?

It's an easy one to hit and hard to diagnose, because it fails silently and only on pure black — bg-white/50, bg-red-500/50 and custom theme tokens all work, so it reads like a config problem rather than a compiler bug. bg-black/50 is common enough (overlays, scrims, image washes) that it costs a while to track down.

Confirming the merged fix does resolve it on lightningcss 1.30.1 — I compiled a Tailwind v4 global.css through the real two-stage pipeline (@tailwindcss/postcss, then compile(css).stylesheet()) and A/B'd bg-black/70:

vanilla 3.0.7        {"backgroundColor":"#NaNNaNNaNb2"}
3.0.7 + #351         {"backgroundColor":"#000000b2"}

One detail worth noting: in the first lightningcss pass the powerless a/b channels surface as null, not NaN — it's the second pass re-parsing the emitted oklab(0% none none / .7) text that yields NaN. So Number.isNaN is the right guard at the point parseColor sees it, but null coords would slip through if that ever changes.

Interim workaround for others blocked on this — patch parseColor with the diff from #351 (bun patch react-native-css / patch-package). Note that hexColors: false and colorPrecision are not workarounds: they make the compiler emit raw oklab(...) strings RN can't parse at all, which breaks every opacity utility instead of just black.

[github-actions]

🤖 Auto-triage

Status: NOT_A_BUG
Type: support
Version: v5 (preview.4) / react-native-css 3.0.7

Findings

This is a release request, not a new bug. The underlying issue (bg-black/NN producing #NaNNaNNaN) was already fixed in #351 (commit f70c402, "fix: coerce NaN Lab/OKLab channels to 0 in parseColor") and merged to main. npm view react-native-css version still returns 3.0.7, so the fix is unreleased. The reporter has already confirmed the merged fix resolves the problem via a two-stage @tailwindcss/postcss → compile() A/B test.

What I tested

• gh issue view 403 — read the issue body (no new repro required; reporter validated fix: coerce NaN Lab/OKLab channels to 0 in parseColor #351 themselves)
• npm view react-native-css version → 3.0.7 (confirms release still pending)
• git log — confirmed f70c402 ("fix: coerce NaN Lab/OKLab channels to 0 in parseColor (fix: coerce NaN Lab/OKLab channels to 0 in parseColor #351)") is on main
• No Jest triage test written — the underlying bug is already covered by the fix in fix: coerce NaN Lab/OKLab channels to 0 in parseColor #351; this issue is about publishing, not code

Next steps

• Cut a 3.0.8 patch release to ship fix: coerce NaN Lab/OKLab channels to 0 in parseColor #351 to npm.
• Consider the reporter's follow-up observation: in the first lightningcss pass the powerless a/b channels surface as null (not NaN), and only the second re-parse of the emitted oklab(0% none none / .7) yields NaN. Number.isNaN is correct at the current guard point, but if upstream behavior ever changes to pass null through, the guard would need to also handle null. May be worth a defensive follow-up (value == null || Number.isNaN(value)) and a compiler test asserting bg-black/50 → #00000080 from both single-pass and re-parsed OKLab input, to prevent regression.

---

_{This is an automated triage. See auto-triage.yml.}