React 19×Rustツール 進化の「ズレ」を設計で埋める

React 19はServer Components・Actions・Suspenseの刷新により、データフェッチからレンダリングまでの体験を一変させました。しかし同時期、Rust製のoxfmtをはじめとする「高速・単機能」ツール群が既存エコシステムを塗り替えつつあります。見落とされがちな問題があります。ライブラリ本体の進化とツールチェーンの進化は同じ速度では進まないということです。新しいレンダリングモデルに最適化されたlintルールはまだない、CIの前提が変わっているのにパイプラインは旧来のまま──こうした「ズレ」がチームの開発体験を静かに蝕みます。本セッションでは、この1年のReact周辺とフロントエンドツールの動向を俯瞰し、両者のギャップをチーム開発・モノレポ構成・CI設計でどう埋めるかを具体事例とともに考えます。「最新を追う」だけでは得られない地に足のついた設計指針をお届けします。

Transcript

1. React 19×Rustツール 進化の「ズレ」を設計で埋める FEC名古屋 hayashi takao
2. 自己紹介 { "name": "Hayashi Takao", "handle": "takao-h", "Rem", "affiliation": "zozo, inc." "github": "https://github.com/takao-h", "x": "@www_REM_zzz", "short_bio": "Web Developer / Software Engineer", "topics": ["TypeScript", "React", "Frontrend"] }
3. このトークで話すこと 1. なぜズレがおきるのか 2. どこに摩擦がでるか 3. 何を設計し直すべきか 4. まとめ
4. 進化の“ズレ”とは何か • React の新しい機能に対して、既存の lint ルールや CI 設計 が追いつかない。 • ツール導入だけが先行し、コードベースやチーム運用が置い ていかれる。 • このズレが静かに DX を悪化させる。
5. この 1 年で何が起きたか? React 19 が変えたもの • 2024年12月、React 19 がリリース。 • Actions により、更新処理を React のフロー に載せやすくなった。 • useActionState により、フォーム送信や非 同期アクションの state 管理をまとめやすく なった。 • useOptimistic により、楽観的 UI 更新が標 準機能として扱いやすくなった。 • use() と Suspense の進化で、非同期 UI の 書き方がより宣言的になった Rust Tooling が変えたもの • 2025年3月、oxlint Beta が公開。 • ルール数は 205 から 502、デフォルト有効 は 70 から 99 に拡大。 • 2025年11月、oxfmt Alpha が公開。 • oxfmt は Prettier 互換を志向しつつ、30倍 超高速を打ち出した。 • format / lint / build を分離して再設計する流 れが強まった
6. 現場で起きる摩擦 • フォーマッタや lint の責務が曖昧になる • CI のジョブ構成が古いままでツールの速さを活かせない • モノレポや複数アプリ構成で設定が増殖する • チーム内で「何を変えるべきか」の合意が取りにくくなる
7. ズレが表面化する瞬間 例えば... React 19 に上げたら eslint-plugin-react が "use client" を認識せず lint エラーが大量発生。 1. React 19 へアップグレードした。 2. すると eslint-plugin-react 周辺で "use client" を前提にした実装が正しく扱えず、 lint エラーが大量に発生した。 3. CI が lint エラーで落ち、リリースを止めざるを得なくなった。 4. 問題は React の機能そのものではなく、周辺ツールと運用設計が追いついていな かったことだった。
8. ズレが表面化する瞬間 モノレポだったら... • apps/web は React 19 + 新しい hooks 記法、packages/storybook は古い JSX 方針、packages/admin はまだ移行途中。 • それなのに oxfmt / oxlint を全体適用すると、あるパッケージでは正しく、別のパッ ケージではノイズになる。 • 「どこまでを一括適用するか」の判断が必要になり、導入しただけでは安定しない
9. oxfmt をどう位置づけるか oxfmt を単なる「速い Prettier 代替」としてではなく、 役割分離の象徴 として捉える。 format は format、lint は lint、型は型として責務を分ける考え方 が大事。 大事なのはツールを比較するより 「どういう境界で導入するか 」。
10. チーム開発での実践パターン パターン1: 先に lint の“観測モード”を作る。 → 強制はせず、まず警告だけ出して false positive の量を把握する。 パターン2: package 単位で rollout する。 → Web アプリ、UI ライブラリ、Storybook、共有 utils を同時に変えない。 パターン3: 設定変更を小さくし、revert できる単位で進める。 パターン4: レビュー観点を分ける。 → React の変更を見る人と、ツール設定を見る人を同じにしない。
11. まとめ • フロントエンドは日々進化している。 • 導入する側にも変化を受け止める設計が必要だった。 • 「最新を追う」のではなく、「変化に耐える基盤をつくる」。 • 個別ツールの更新に振り回されず、開発環境全体を見据えて 設計する。