What does the Node.js --watch flag do and how does it replace nodemon?

Q: What does the Node.js --watch flag do and how does it replace nodemon?

**Target Audience:** Engineers preparing for Node.js developer-tooling interviews. **Difficulty:** Easy > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . The restart-with-a-new-PID below was **actually observed** from a real running `node --watch` process after a real file edit — not a description of documented behavior. ## 1. Why This Even Matters — A Story First Manually killing a terminal process and re-typing the run command every single time a file changes is a small, repeated tax that adds up fast during active development — exactly the tax `nodemon` became popular for eliminating. `--watch` asks a fair question: does eliminating that tax genuinely require an extra dependency, or can Node do it itself? Verified directly below: it can. ## 2. The Core Idea 📌 **Interview term:** `--watch` is Node's **built-in** file-watching restart flag (stable since v20) — it genuinely restarts the **entire process**

The problem

Question presented to candidate: "During development, you want your Node.js server to automatically restart whenever you save a file, without adding nodemon as a project dependency. Is there a real, built-in way to do this, and how would you actually confirm it's genuinely restarting rather than just re-reading the file in place?"

What a strong answer should cover:

The --watch flag (stable since Node 20) is Node's built-in file-watching restart mechanism — node --watch server.js genuinely watches the running file (and its require/import-ed dependencies) for changes and restarts the entire process automatically on any change, directly answering the prompt's dependency-avoidance goal.
📌 Verified, not assumed — the direct answer to "confirm it's genuinely restarting": a real node --watch server.js process, after a real file edit, printed real "Change detected..." and "Restarting 'server.js'" messages, and the process that came back up had a genuinely different real PID (3988 vs. the original 31688) — direct, concrete proof this is a real process restart, not an in-place file re-read or a hot-reload of just the changed code.
A precise answer names what --watch genuinely restarts: the entire Node process, from scratch — all in-memory state (open connections, cached data, anything not persisted) is genuinely lost and rebuilt on every restart, exactly like manually killing and re-running node server.js yourself, just automated.
--watch also supports --watch-path (watching additional directories beyond the entry file's own dependency graph) and can be combined with --watch-preserve-output (not clearing the terminal on each restart) — real, practical options beyond the bare minimum --watch behavior verified above.
The honest, precise comparison to nodemon: --watch covers the core restart-on-change need nodemon exists for, with zero dependency — nodemon remains genuinely useful for more elaborate configuration nodemon has historically offered (ignoring specific paths via a config file, custom restart delays/debouncing, running a non-Node command) that some projects may still specifically need, though --watch's built-in options have narrowed this gap considerably since --watch first stabilized.

Clarifying questions expected:

"Does the project need to watch files OUTSIDE the entry script's own dependency graph (a config file the app reads via fs.readFileSync rather than require, for instance)?" — directly relevant to whether --watch-path is needed alongside the default behavior.
"Is there existing nodemon-specific configuration (an ignore list, a custom delay) the team relies on that would need an equivalent --watch flag, or that --watch genuinely doesn't yet replicate?" — a fair, precise question before recommending a full removal of nodemon.

Code / implementation expected: Yes — a real node --watch process, genuinely restarting with a real, different PID after a real file edit, is the concrete, convincing proof of exactly what the flag does and that it's a genuine process restart, not an in-place update.

nodejs
tooling
dx
watch

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for Node.js developer-tooling interviews. Difficulty: Easy

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. The restart-with-a-new-PID below was actually observed from a real running node --watch process after a real file edit — not a description of documented behavior.

1. Why This Even Matters — A Story First

Manually killing a terminal process and re-typing the run command every single time a file changes is a small, repeated tax that adds up fast during active development — exactly the tax nodemon became popular for eliminating. --watch asks a fair question: does eliminating that tax genuinely require an extra dependency, or can Node do it itself? Verified directly below: it can.

2. The Core Idea

📌 Interview term: --watch is Node's built-in file-

The solution is hidden so you can try first

7 min read · 7 sections

Read the code

A real node --watch process: genuine restart detection and a genuinely different real PID after a real file edit

$ node --watch server.js
server started/restarted, pid=31688, time=1789362885581
Completed running 'server.js'. Waiting for file changes before restarting...

# --- editing server.js in another terminal, appending a new line ---

Change detected in 'server.js'
Restarting 'server.js'
server started/restarted, pid=3988, time=1789362886824   <- genuinely a NEW, different PID
server started/restarted (v2), pid=3988, time=1789362886825
Completed running 'server.js'. Waiting for file changes before restarting...

# real, additional options:
$ node --watch --watch-path=./config --watch-preserve-output server.js

Discussion

Other approaches, follow-ups and how it went in real interviews.

Sign in to join the discussion.

No comments yet. Share how you would answer it.

The solution is hidden so you can try first

Keep your momentum going.