Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Endlessly restart #94

Closed
akanass opened this issue Oct 21, 2015 · 9 comments
Closed

Endlessly restart #94

akanass opened this issue Oct 21, 2015 · 9 comments

Comments

@akanass
Copy link

akanass commented Oct 21, 2015

Hello,

When I specify watching array, in config object, with more one element, nodemon is restarting endlessly:

return nodemon({
        script: './index.js',
        ext: 'html js json',
        watch: ['lib', 'test'],
        tasks: ['lint']
    });

Result in console log:

[11:17:07] [nodemon] 1.7.3
[11:17:07] [nodemon] to restart at any time, enter `rs`
[11:17:07] [nodemon] watching: /lib/**/* /test/**/*
[11:17:07] [nodemon] starting `node ./index.js`
[11:17:09] [nodemon] restarting due to changes...
[11:17:10] Using gulpfile ~/gulpfile.js
[11:17:10] Starting 'lint'...
[11:17:10] Finished 'lint' after 150 ms
[11:17:11] [nodemon] restarting due to changes...
[11:17:12] Using gulpfile ~/gulpfile.js
[11:17:12] Starting 'lint'...
[11:17:12] Finished 'lint' after 173 ms
[11:17:13] [nodemon] restarting due to changes...

If I put only one element in this array, works fine:

return nodemon({
        script: './index.js',
        ext: 'html js json',
        watch: ['lib'],
        tasks: ['lint']
    });

Result in console log:

[11:19:19] [nodemon] 1.7.3
[11:19:19] [nodemon] to restart at any time, enter `rs`
[11:19:19] [nodemon] watching: /lib/**/*
[11:19:19] [nodemon] starting `node ./index.js`

My node version is v4.2.1 and worked fine before.

Thanks for your help.

@pipmurphy
Copy link

We're getting similar behaviour. Works fine with one element in the watch array, but constantly restarts if more than one watched folder.

(By specifying a function for the tasks option, it's possible to find out which files it considers to have changed - with more than one watched folder, it seems to think that old, unchanged files have changed.)

@bsouthga
Copy link

installing nodemon@1.4.1 manually fixed the issue of incessant restarts for us (looks like it was an issue with the newer underlying nodemon version 1.7.3)

@Velveeta
Copy link

Right, I'm about to push a PR to temporarily fix this by just modifying the gulp-nodemon package.json file to reference nodemon <=1.7.1... There's a downstream change from the chokidar module that's causing a lot more 'add' events to be published, and the timing seems to be out of whack with the 'ready' events they publish, so that when passing an array of file watches, it alerts 'ready' for completion if each segment of files... When nodemon receives the first 'ready' event, it then calls its filterAndRestart function everytime a new 'add' event comes in, which is every single file read in by chokidar after that first 'ready' event gets alerted, which causes it to constantly recycle the process as it adds more and more files to its watch. Oddly enough, running nodemon by itself doesn't seem to cause this problem when a file is saved, so it seems to be something related to how gulp-nodemon is passing the file list to nodemon (maybe?). In any case, running vanilla nodemon, I don't get the magic of running additional gulp tasks when certain file types change, so this change to restrict the nodemon version to prior to them bumping up their chokidar version to 1.2.0 seems to fix it for now.

@markstos
Copy link
Contributor

This issue was caused a bug in a nodemon, in combination with a dependency specified by gulp-nodemon that allowed the broken dependency of nodemon to be used. The issue is somewhat resolved because nodemon has released version 1.8.0. To avoid similiar issues in the future, gulp-nodemon could be more precise about what version it requires. For example, if "~1.4.1" was specified as the version instead of "^1.4.1" then the broken nodemon 1.7.3 would never been selected as a dependency.

There are trade-offs for the gulp-nodemon project. If the version dependency continues to be managed loosely, there will continue be issues opened here if nodemon breaks something again. On the other hand, if the version is managed tightly, periodic releases of gulp-nodemon will be needed to "keep up", otherwise different issues will be opened asking for gulp-nodemon to upgrade the dependency

@markstos
Copy link
Contributor

Another approach is to keep the acceptable range of the nodemon dependency broad, but blacklist the problematic range:

`>=1.4.1 <1.7.0 || >=1.8.0 <2.0.0`

@ColemanGariety
Copy link
Owner

@markstos pushed the latest with nodemon 1.8.1, but considering using your blacklist. The problem is that if someone happens to have nodemon 1.7.x installed, then Node will pick it up?

If that's not the case, then such a blacklist probably isn't necessary, but I'm not exactly sure how the ^ works in package versions.

@markstos
Copy link
Contributor

Thanks, @JacksonGariety. Where I can find out how I could use a blacklist?

Perhaps you are referring to the ability to specify ranges of allowed or excluded versions in package.json dependency lists. As I understand, I depend on gulp-nodemon and don't have control over the version of nodemon that gulp-nodemonrequires, so that the place to specify an exclusion would be thegulp-nodemon` package.json, not in my own.

Regarding how caret versions work, they are documented in the semver package.

@ColemanGariety
Copy link
Owner

@markstos my thinking was that you'd fork gulp-nodemon and edit it to use the blacklist. Then put that fork in your package.json as specified here: https://docs.npmjs.com/files/package.json#git-urls-as-dependencies

If that blacklist works we'll merge it in with master so other people don't accidentally end up with the nodemon 1.7.x bug.

@markstos
Copy link
Contributor

I see. I don't plan to fork the project, as I've solved the issue for myself. You might still want to update your version syntax to to exclude the problematic versions as I previously recommended to avoid the possibility of more support requests landing here.

`>=1.4.1 <1.7.0 || >=1.8.0 <2.0.0`

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants