Hacktoberfest 2026：維護者為十月標記出來的 issue，仍然開放、適合新手。 瀏覽 Hacktoberfest issue

rtl:/ltr: variants silently dropped — lightningcss downcompiles :dir() to :lang() which is unhandled

未關閉
  • 哪裡不對？
#453 2 則留言 1 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 3 天內回覆

@YevheniiKotyrlo 已經在處理了。

開始於 2026年9月22日。

  • #461 來自 @YevheniiKotyrlo —— 未關閉
  • #472 來自 @Abdalkaderdev —— 未關閉

評估

難度
4/5
預估耗時
3-5 天
新手友好度
35/100
Issue 類型
缺陷
描述清晰度
描述清楚
活躍度
活躍
技術堆疊
css, react-native, typescript
領域
frontend, mobile

研究方向

Start in selector-builder.ts at parseIsWhereComponents, comparing the existing case "dir" branch with the default branch that returns null for :lang(). Check how :where() handles [dir="rtl"] attribute selectors. Two open pull requests (#461, #472) already target this, so read them before starting. Done means an rtl: class applies its style when I18nManager.isRTL is true, and the existing selector tests still pass.

由索引模型根據 Issue 內容生成。

描述

Describe the bug

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

  1. Tailwind v4 generates :dir(rtl) in the rtl: variant (confirmed in tailwindcss source)
  2. Lightningcss 1.30.1 downcompiles :dir(rtl) to :is(:lang(ae), :lang(ar), ...) at the parse level
  3. parseIsWhereComponents in selector-builder.ts has a case "dir" handler but no case "lang" handler
  4. :lang() hits default: { return null; } → returns null
  5. Inside :where(), [dir="rtl"] attribute selectors also return null (line ~397)
  6. 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:

case "lang": {
  const RTL_LANGUAGES = new Set([
    "ae","ar","arc","bcc","bqi","ckb","dv","fa","glk",
    "he","ku","mzn","nqo","pnb","ps","sd","ug","ur","yi"
  ]);
  const direction = component.languages?.[0] && RTL_LANGUAGES.has(component.languages[0]) ? "rtl" : "ltr";
  queries ??= [{ specificity: [] }];
  queries.forEach(query => {
    getMediaQuery(query).push(["=", "dir", direction]);
  });
  return parseIsWhereComponents(type, selector, index + 1, queries);
}

Reproduction

Steps:

  1. npm install && npx expo run:ios
  2. Press "Force RTL" button
  3. Fully restart the app
  4. The rtl:bg-amber-400 class should make the background amber, but it stays blue

Expected behavior

rtl:bg-amber-400 should apply background-color: amber-400 when I18nManager.isRTL === true.

Workaround

Use patch-package with the patch from the fix branch.

Environment

  • react-native-css: 3.0.7
  • nativewind: 5.0.0-preview.4
  • react-native: 0.86.0
  • expo: 57
主要語言
TypeScript
星號
166
分支
45
平均合併
13 天 14 小時
30 天內合併 PR
1

環境準備

  • 沒有 Dockerfile 或 Docker Compose 檔案
  • 沒有 Pull Request 範本
  • 閱讀貢獻指南

從這裡開始

  1. 先讀完整個 Issue，再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫，在一個分支上完成修改。
  4. 送出 Pull Request，並在描述裡引用這個 Issue 編號。

nativewind/react-native-css 的其他 Issue

查看 nativewind/react-native-css 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。