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

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.

Start in lib/internal/test_runner/runner.js, especially the watchFiles 'changed' handler around lines 659-672 and the isolation-none watch setup in run(). Reproduce the issue with the two-file commands from the report, then trace how owners and testFiles are passed to the fresh child. Done means the intended affected-file behavior is implemented or the documented isolation behavior is explicitly resolved and covered by tests.