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**

01

Understand 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.

nodejstoolingdxwatch

02

Attempt it yourself

Sketch your approach before reading the solution — that's what interviews test.

Nudge consolestandby

Stuck? Beam a request up — the console returns a conceptual nudge that guides your logic without spoiling the implementation.

03

Study the 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 --wa

Solution ready — 2 min read

Classified // press E to declassify

04

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

05

Join the discussion

Discussion (0)

Sign in to join the discussion.

No responses yet. Be the first to share what you think.