Failure to trigger restart on symlink target change
0 reputation · 09 May 2021, 09:36 UTC
0 reputation · 09 May 2021, 09:36 UTC
Nodemon monitors file system events to automate application restarts upon file modifications. Documented behavior indicates inconsistent handling of symbolic links across file systems.
When a watched path contains a symlink, changes to the target directory or file may not be observed if the symlink inode or metadata remains unchanged. This creates uncertainty about whether the running application reflects updates made through the linked path.
Does nodemon detect modifications to the contents of a symlink target when the link itself is not modified? Is there a configuration option to force re-evaluation of symlinked directory trees? How is symlink monitoring behavior documented across platforms?
35275 reputation · 09 May 2021, 19:02 UTC
Nodemon watches the file system for modify, create, and delete events on the paths you specify. When the watched path is a symbolic link, the underlying watcher (inotify on Linux, FSEvents on macOS, ReadDirectoryChangesW on Windows) tracks the inode of the link itself, not the inode of the file or directory it points to. Therefore, editing a file through the symlink does not generate a modify event on the link, and Nodemon will not restart.
modify on the target.--follow-symlinks option only affects the initial scan; it does not cause the watcher to listen to changes inside the target tree.--watch.
nodemon --watch /absolute/path/to/real/dir app.jsnodemon -L app.jsnodemon --watch "**/*.js" app.js will recurse into the target directory if the glob matches files inside it.touch /path/to/target/file.js and observe whether Nodemon restarts.ignored in the message.ls -l /path/to/symlink.--legacy-watch).Is the symlink pointing to a location that resides on a different file system or inside a container volume? This context can change the recommendation, as cross‑filesystem links often require the legacy watch mode.
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 09 May 2021, 17:06 UTC
One distinction worth separating: editing a file inside the original target and repointing the symlink to a new directory are different events. Repointing the link changes the link entry itself, which may trigger a restart, but nodemon does not necessarily re-resolve and watch the new target tree afterward. A restart after a link swap therefore does not guarantee the new directory is under active surveillance.
If you watch both the symlink and the resolved real path to cover this gap, the same file can be reachable through two paths. Extension and ignore rules need to account for both, or a single save may produce duplicate restarts.
Because behavior depends on the platform watcher and the installed nodemon release, verify with a controlled test: edit inside the original target, repoint the link, then edit inside the new target. Compare results against watching the real path directly, and check your installed version's help output for watch-related flags before relying on any polling or legacy mode.