Add an ignore/exclude option to --watch (fixes infinite restart loop when a watched process writes+imports a file, e.g. Vite createServer)

What is the problem this feature will solve?

node --watch enters an infinite restart loop when the watched process itself writes a file and then dynamically imports it during startup. The watcher adds the freshly-written, now-imported file to its watch set, sees it as "changed," and restarts — which re-runs the same write-and-import, restarting again, forever.

The most common real-world trigger is starting a Vite dev server in middleware mode under node --watch: Vite's config loader writes a temporary config file and await import()s it during createServer(). There is currently no way to exclude that file (or node_modules, or any generated/temp path) from --watch, so the loop cannot be worked around with native flags.

Today node --watch only offers --watch, --watch-path, and --watch-preserve-output. There is no ignore/exclude option. (#45467 is the inverse request — adding paths to watch.)

Minimal reproduction

In any project with vite installed, create repro.mts:

import { createServer } from "vite";
const v = await createServer({ appType: "custom", server: { middlewareMode: true } });
console.log("VITE_UP", typeof v.middlewares);
setInterval(() => {}, 1000);

Run:

node --watch repro.mts

Observed

VITE_UP function
Restarting 'repro.mts'
VITE_UP function
Restarting 'repro.mts'
... (repeats indefinitely)

Reproduced on every version tested (darwin arm64), ~34–35 Restarting cycles in ~15 seconds:

Node version	Result
22.23.1	loops (35 boots / 35 restarts)
24.13.1 (latest LTS)	loops (34 boots / 34 restarts)
23.x	loops (per linked Vite issue)

Expected

The process boots once and stays up until a source file the developer actually edits changes — i.e. files written and imported by the process itself during startup should not be able to trigger a restart, or there should be a way to exclude them.

Root cause

Per the analysis in vitejs/vite#19854, Vite's config loading writes a temp file and immediately dynamic-imports it (return (await import(pathToFileURL(tempFileName).href)).default). Inserting a delay between the write and the import stops the loop, confirming a race between the process's own write+import and --watch's file monitoring. Because --watch watches every imported file and has no exclude mechanism, the generated file becomes a restart trigger.

What is the feature you are proposing to solve the problem?

An ignore/exclude option for watch mode, e.g.:

node --watch --watch-exclude='**/node_modules/**' --watch-exclude='**/.vite-temp-*' app.mts

(name/spelling open — --watch-exclude or --watch-ignore, glob-based, repeatable). This would let developers exclude node_modules, build caches, and temp/generated files from triggering restarts, which resolves this loop and matches what every userland watcher (nodemon, tsx, chokidar-based tools) already provides.

Optionally/additionally: do not let files written by the watched process after startup began count as external changes for the initial run.

What alternatives have you considered?

• --watch-path — scopes what is watched but cannot exclude a sub-path or generated file from an otherwise-watched tree, so it doesn't fix this.
• Userland watchers (tsx watch, nodemon) — these do not loop on the identical reproduction because they watch only the static import graph and/or support ignore globs. This is the gap relative to native --watch.

Related issues / downstream reports

• vitejs/vite#19854 — Node --watch + createServer() infinite reload loop (closed as "not planned"; no determination of whether it's a Vite or Node issue).
• nubjs/nub#204 — same loop via nub watch, which wraps Node's native --watch (identical Restarting '<file>' output).

Comece pelo ponto de entrada node --watch e execute a reprodução mínima do Vite com createServer() para observar o loop de reinicialização. Determine a semântica compatível de exclude ou ignore e, em seguida, verifique se opções glob repetíveis impedem que arquivos gerados ou temporários acionem reinicializações, enquanto as alterações nos arquivos de origem continuam acionando-as.