test_runner: `--watch` with `--test-isolation=none` reruns every test file, not the affected one
还没有人认领这个 Issue。
- 主要语言
- JavaScript
- 星标
- 122k
- 派生
- 37.4k
- 平均合并
- 4 天 3 小时
- 30 天内合并 PR
- 272
描述
Version
v26.5.0
Platform
Darwin 25.5.0 arm64
(Not platform-specific — it falls out of lib/internal/test_runner/runner.js.)
Subsystem
test_runner
What steps will reproduce the bug?
Two test files; edit only the first and see which ones re-run.
mkdir -p /tmp/probe && cd /tmp/probe
printf 'const {test}=require("node:test");\ntest("A-ran",()=>{});\n' > a.test.js
printf 'const {test}=require("node:test");\ntest("B-ran",()=>{});\n' > b.test.js
# Run once with, once without --test-isolation=none.
# After the first run settles, append a comment to a.test.js and watch the output.
node --test --watch a.test.js b.test.js
node --test --test-isolation=none --watch a.test.js b.test.js
Output produced after touching a.test.js only:
=== default isolation ('process') ===
✔ A-ran (1.202958ms)
ℹ tests 1
=== --test-isolation=none ===
✔ A-ran (0.673791ms)
✔ B-ran (0.116333ms)
ℹ tests 2
How often does it reproduce? Is there a required condition?
Every time. The required condition is --watch together with --test-isolation=none
(equivalently run({ watch: true, isolation: 'none' })).
What is the expected behavior? Why is that the expected behavior?
Only a.test.js re-runs. That is what the documentation promises, without an
isolation caveat — Watch mode:
In watch mode, the test runner will watch for changes to test files and their
dependencies. When a change is detected, the test runner will rerun the tests
affected by the change.
The isolation option's own docs describe it purely as where tests run ("all
test files run in the current process"), so nothing signals that it also changes
which files a change re-runs.
What do you see instead?
Every test file in the run re-runs on every change.
The two modes take different branches in watchFiles' 'changed' handler
(lib/internal/test_runner/runner.js#L659-L672):
if (opts.isolation === 'none') {
PromisePrototypeThen(restartTestFile(kIsolatedProcessName), undefined, (error) => {
triggerUncaughtException(error, true /* fromPromise */);
});
} else {
watcher.unfilterFilesOwnedBy(owners);
PromisePrototypeThen(SafePromiseAllReturnVoid(testFiles, async (file) => {
if (!owners.has(file)) {
return;
}
await restartTestFile(file);
}, ...));
}
kIsolatedProcessName is the sentinel for the single child that runs the whole
file list, set up in run() under the matching isolation === 'none' && watch
branch — so owners (the set of files the change actually affects) is computed
and then discarded.
Additional information
This looks fixable rather than inherent. The isolation: 'none' watch path
still spawns a fresh child process per change, so there is no ESM
module-cache obstacle to re-running a subset — the child could be given
owners instead of the full testFiles.
The obvious counter-argument, and the reason this might be deliberate: under isolation: 'none' files share a process and can therefore share module-level state, so a subset run is not always equivalent to the full run. Although that probably indicates an unintended coupling between test suites! If that is the rationale, it would be worth stating in the docs — as written they promise the incremental behavior unconditionally.
The practical cost is that --test-isolation=none and --watch pull in opposite directions. Isolation none exists to amortize an expensive import graph across many files, which pays off for a whole-suite run. Watch mode's value is that a save costs one file. Combining them gives you neither: in a suite where the shared import cost is what motivated isolation: 'none' in the first place (ours is ~575 files behind a large DI container), every keystroke-save re-runs everything.
Happy to open a PR for whichever direction maintainers prefer (scope the child to owners, or document the difference). I've opened a docs-only PR for the second in the meantime.
贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
调研方向
从 lib/internal/test_runner/runner.js 开始,重点查看第 659-672 行附近的 watchFiles 'changed' 处理器,以及 run() 中 isolation-none 的 watch 设置。使用报告中的双文件命令重现问题,然后追踪 owners 和 testFiles 如何传递给新的子进程。完成的标准是实现预期的受影响文件行为,或者明确解决文档所述的 isolation 行为,并由测试覆盖。
由索引模型根据 Issue 内容生成。
评估
- 技术栈
- javascript
- 领域
- testing
- Issue 类型
- 缺陷
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 活跃度
- 冷清
- 描述清晰度
- 基本清楚
- 新手友好度
- 45/100