You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
rtl:/ltr: variants silently dropped — lightningcss downcompiles :dir() to :lang() which is unhandled #453
The rtl: and ltr: variants from Tailwind CSS v4 are silently dropped during compilation. No error is produced — the styles simply never apply. Related to nativewind/nativewind#1433 but traced to a different root cause in the react-native-css v5 compiler.
Root cause
Tailwind v4 generates :dir(rtl) in the rtl: variant (confirmed in tailwindcss source)
Lightningcss 1.30.1 downcompiles :dir(rtl) to :is(:lang(ae), :lang(ar), ...) at the parse level
parseIsWhereComponents in selector-builder.ts has a case "dir" handler but no case "lang" handler
Inside :where(), [dir="rtl"] attribute selectors also return null (line ~397)
ALL alternatives produce nothing → the entire rule is silently dropped
Key finding: Features.DirSelector does not help
Adding Features.DirSelector to lightningcss include list does NOT prevent the downcompile. Confirmed with a console.log verifying the flag IS loaded — the CSS output still contains :is(:lang(...)) instead of :dir(rtl). The downcompile happens at the parse level, before feature flags are consulted.
Proposed fix
Add a case "lang" handler to parseIsWhereComponents. Lightningcss expands :dir(rtl) into a fixed set of 19 RTL languages. Map these back to [=, "dir", "rtl"], leveraging the existing runtime case "dir" check against I18nManager.isRTL:
Our automated reproduction pipeline could not conclusively judge this bug. See the CI run for the captured evidence. A maintainer will take a closer look.
Cannot assess whether the bug reproduces because the iOS build completed but failed to bundle the JavaScript code (main.jsbundle missing). The app would not run the user's test case with the rtl:bg-amber-400 class, making it impossible to observe whether the variant is silently dropped as reported.
Platform
Verdict
Evidence
ios
inconclusive
repro_status indicates 'bundle-missing' — no main.jsbundle was embedded, so user JS would not run. Build succeeded but the app cannot execute the reproduction test case.
This no longer reproduces on main. I checked with @tailwindcss/postcss through the repo's own test harness:
rtl:text-white → { color: '#fff' } when I18nManager.isRTL is true, nothing when false
ltr:text-white → the inverse
So the :lang() form that lightningcss downcompiles :dir() into is being handled somewhere now, and parseIsWhereComponents no longer drops the rule.
What was missing was anything to keep it fixed — the existing ltr: test never sets isRTL, so it passes even if the condition is dropped and the style applies unconditionally, and there was no rtl: test. Opened #472 with both directions and the negative case.
Worth confirming on your repro branch before closing, in case your setup differs — your repro pins react-native-css 3.0.7 and this was against main.
Activity
github-actions commentedon Jul 22, 2026
❓ Inconclusive
Our automated reproduction pipeline could not conclusively judge this bug. See the CI run for the captured evidence. A maintainer will take a closer look.
Cannot assess whether the bug reproduces because the iOS build completed but failed to bundle the JavaScript code (main.jsbundle missing). The app would not run the user's test case with the rtl:bg-amber-400 class, making it impossible to observe whether the variant is silently dropped as reported.
Automated by
.github/workflows/issue-repro.ymlusing agent-device. Workflow run: https://github.com/nativewind/nativewind/actions/runs/29952432645Abdalkaderdev commentedon Oct 8, 2026
This no longer reproduces on
main. I checked with @tailwindcss/postcss through the repo's own test harness:rtl:text-white→{ color: '#fff' }whenI18nManager.isRTLis true, nothing when falseltr:text-white→ the inverseSo the
:lang()form that lightningcss downcompiles:dir()into is being handled somewhere now, andparseIsWhereComponentsno longer drops the rule.What was missing was anything to keep it fixed — the existing
ltr:test never setsisRTL, so it passes even if the condition is dropped and the style applies unconditionally, and there was nortl:test. Opened #472 with both directions and the negative case.Worth confirming on your repro branch before closing, in case your setup differs — your repro pins react-native-css 3.0.7 and this was against
main.fix(metro): compile the native stylesheet from the authored CSS, neve…