Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

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

未关闭
  • 哪里不对？
#520 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

@borisyankov 已经在做这个了。

开始于 2026年9月23日。

  • #521 来自 @borisyankov —— 未关闭

评估

难度
5/5
预计耗时
一周以上
新手友好度
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

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

react/react-strict-dom 的其他 Issue

查看 react/react-strict-dom 的全部 Issue

相似的 Issue

更多 JavaScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。