Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

postcss plugin re-transforms every included file on each rebuild under Turbopack (minutes-long HMR in large projects)

オープン
  • 何か問題がありますか？
#520 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

@borisyankov がすでに取り組んでいます。

2026年9月23日 から。

  • #521 @borisyankov による — オープン

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
javascript, next.js, react
領域
build-system, performance, tooling

調査の方向性

postcss-react-strict-dom/src/builder.js とその fileModifiedMap から始め、次に、Turbopack と webpack を使う next dev の下で、多数の一致するファイルを含む合成プロジェクトによってインクリメンタルな動作を再現します。再ビルド間のキャッシュ動作を比較します。Turbopack の無効化後もインクリメンタル抽出が有効であり続けるか、文書化された webpack の回避策が追加され、検証されれば完了です。

索引モデルが issue の本文から書いたものです。

説明

Summary

In a Next.js 16 app using react-strict-dom/postcss-plugin, every incremental rebuild under Turbopack (the default dev bundler) re-transforms all files matched by the plugin's include globs, not just the changed file. In a large monorepo (~4,000 included source files) this makes a one-line edit take ~80 seconds to rebuild, while the same edit under next dev --webpack rebuilds in ~4 seconds.

Environment

  • react-strict-dom: 0.0.55 (postcss-react-strict-dom 0.0.55)
  • next: 16.2.11 (Turbopack dev)
  • node: 22.x, macOS (M-series)
  • postcss.config.js: react-strict-dom/postcss-plugin with include globs covering the app + shared workspace packages (~4,000 .ts/.tsx files), useLayers: true, and the documented babelConfig with react-strict-dom/babel-preset

Measurements (same machine, same session)

Scenario Time
Cold compile of one route (Turbopack) ~50s
One-line edit to any file matched by include (Turbopack) ~80s
Edit to a file NOT matched by include (Turbopack) 0.35s
One-line edit, next dev --webpack 4.4s

Creating a new untracked file that matches the globs — even one that nothing imports — also triggers the full ~80s rebuild, since the generated CSS has a dir-dependency on the glob roots.

Analysis

The plugin already has an incremental path: postcss-react-strict-dom/src/builder.js keeps a fileModifiedMap of mtimes and skips unchanged files. But that cache lives in the plugin instance's memory:

  • Under webpack, Next keeps the PostCSS config module (and the plugin closure) alive across rebuilds, so only the changed file is re-transformed → ~4s HMR.
  • Under Turbopack, the PostCSS transform runs in a turbopack-node worker whose module state does not survive the invalidation, so fileModifiedMap is empty on every rebuild and all ~4,000 files are re-parsed and babel-transformed serially in a single worker on every edit.

Profiling during a rebuild shows one Node process (the turbopack-node PostCSS transform) pegged at ~100% CPU for the entire rebuild while everything else idles. A native sample of that process lands almost entirely in Array.prototype.includes via postcss's MapGenerator.previous() (previousMaps.includes(map) per AST node — quadratic when the generated CSS has many nodes with distinct input maps), with the repeated Babel transform pass as the underlying volume of work.

Suggested fixes

  1. A persistent (disk-backed) cache for the per-file transform results, keyed by path + mtime/content hash (similar to Tailwind's approach), so extraction stays incremental regardless of the host process lifecycle.
  2. Alternatively/additionally: a note in the Next.js setup docs that large projects should currently prefer next dev --webpack, since Turbopack defeats the plugin's in-memory cache.

Repro

I can't share the affected monorepo, but the behavior scales with the number of files matched by include: generating a few thousand small components using css.create from react-strict-dom and pointing the plugin's include at them reproduces the per-edit full re-extraction under next dev (Turbopack) vs the fast incremental path under next dev --webpack. Happy to put together a synthetic repro repo if useful.

主要言語
JavaScript
スター
3.6k
フォーク
208
30日以内にマージされた PR はありません

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

react/react-strict-dom のほかの issue

react/react-strict-dom の issue をすべて見る

似ている issue

JavaScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。