Nodemon restarting twice for a single file change

[day0ops]

Something is causing nodemon to restart twice for a single file change. I haven't quite investigated what it is but my guess is its an underlying library that nodemon uses.

• I have tested this both on v5.11.1 and v6.2.0.
• Im using gulp-nodemon as a wrapper but I cant see anything in gulp-nodemon that would be triggering this.

My initial thought it was either fsevents or chokidar. Any ideas ?

[09:01:06] File /Volumes/STORAGE/Projects/Docker_Packages/agent_management_app/Core/server/views/index.jade was changed
[09:01:06] [nodemon] files triggering change check: server/views/index.jade
[09:01:06] [nodemon] matched rule: **/server/views/**/*
[09:01:06] [nodemon] changes after filters (before/after): 1/1
[09:01:06] [nodemon] restarting due to changes...
[09:01:06] [nodemon] server/views/index.jade
[09:01:06] [nodemon]
[09:01:06] [nodemon] running tasks...
...
[09:01:35] [nodemon] files triggering change check: server/views/index.jade
[09:01:35] [nodemon] matched rule: **/server/views/**/*
[09:01:35] [nodemon] changes after filters (before/after): 1/1
[09:01:35] [nodemon] restarting due to changes...
[09:01:35] [nodemon] server/views/index.jade
[09:01:35] [nodemon]
[09:01:35] [nodemon] running tasks...

[day0ops]

So turns out after some investigation, the set of files/directories its watching is as follows

[ 'client/**/*.js',
  'client/locales/*.json',
  'server/views/**/*.jade',
  'server/config/*',
  'server/**/*.js' ]

And making a change in server/views/index.jade file for.e.g caused it to trigger the watch twice as it is watching not only server/views/**/*.jade but also server/**/*.js.

Why is it that server/**/*.js would cause the second trigger ? And if so shouldnt the matched rule reflect this ?

Fix was ofcourse to change server/**/*.js to server/javascripts/**/*.js

[damienfa]

I also notice that problem ! nodemon restarts twice for a single file change.

I was targeting two different extension (that should be possible) with "ext": "js json" (seen in the doc here : https://github.com/remy/nodemon/blob/master/doc/sample-nodemon.md ).
When I modified only 1 js file, nodemon restarted twice.
If I change my config in order to manage only one extension, the problem is solved.

@nixgadget I've tried your case and it cause twice restart here as well !

[richardgirges]

I started seeing this after upgrading to Node v7.7 from Node v6.9

[leonardodino]

nodemon: v1.11.0 (no global version installed)
node: v7.7.3
nvm: v0.33.0
OS: MacOS 10.12.13 (Sierra)

the delay option didn't work for me with delays shorter than 2s.

it happens on both --exec option and with node .js files.
both long running and short running processes.

temporary fix: enable legacy file pooling

$ nodemon -L index.js

[govindrai]

Any updates on this? Legacy file pooling definitely solves the problem, but a fix would be proper.

[remy]

Govind - can you point me to a PR that fixes this, and I'll merge.

…

On Thu, 7 Sep 2017, 21:06 Govind Rai ***@***.***> wrote: Any updates on this? Legacy file pooling definitely solves the problem, but a fix would be proper. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#854 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAA1hJSDXSxKotIpFR1Vq62YF1H237Csks5sgEzIgaJpZM4I1wr0> .

[stale]

This issue has been automatically marked as idle and stale because it hasn't had any recent activity. It will be automtically closed if no further activity occurs. If you think this is wrong, or the problem still persists, just pop a reply in the comments and @remy will (try!) to follow up.
Thank you for contributing <3

[joshuaquek]

errr... so has a proper fix been implemented? or are we still relying on the -L flag?

[joshuaquek]

nevermind, lets just use the -L flag lol, it works fine without causing any other issues.

[pdiniz13]

why was this issue closed? The problem is still there.

[remy]

Read the comments. No one wanted to fix it, so it became idle and auto closed.

[melvincarvalho]

Same issue here. Trying -L now

[0biWanKenobi]

aaaand it's still happening. the -L solves the problem, but someone maintaining the package should fix this. Otherwise what's even the point of the non-legacy watcher?

[remy]

"someone maintaining the package" - that's nearly 100% of the time just me. "still happening" isn't particularly useful anyone attempting to fix what you're seeing - not that I'm super pumped about the idea. But if you file a proper issue with details of what you see and how to replicate (with code) then you've got a greater chance of the root issue being resolved.