test_runner: `--watch` with `--test-isolation=none` reruns every test file, not the affected one

Bắt đầu trong lib/internal/test_runner/runner.js, đặc biệt là handler 'changed' của watchFiles quanh các dòng 659-672 và phần thiết lập watch của isolation-none trong run(). Tái hiện sự cố bằng các lệnh hai tệp trong báo cáo, sau đó theo dõi cách owners và testFiles được truyền đến tiến trình con mới. Công việc được xem là hoàn tất khi hành vi dự kiến đối với các tệp bị ảnh hưởng được triển khai hoặc hành vi isolation được ghi trong tài liệu được giải quyết một cách rõ ràng và có các bài kiểm thử bao phủ.

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.