gulp-nodemon watcher does not work - node.js

i'm developing a websocket server, I tried to restart the server with nodemon as soon as i change it. However it appears that this is not working for me.
gulp.task('startWebsocketServer', function() {
return nodemon({
script: './server/websocket/server.js',
watch: ['./server/websocket/**/*.js']
});
});
Does anyone have an idea what i did wrong here?
nodemon is on version 1.9.2 and nodejs on 4.2.6.

gulp-nodemon inherits its options from nodemon. Concerning the watch option the docs say this:
By default nodemon will traverse sub-directories, so there's no need in explicitly including sub-directories. [...] Don't use unix globbing to pass multiple directories, e.g --watch ./lib/*, it won't work
So can't and don't need to use a globstar ** in your watch option. Simply specifying the directory should suffice:
gulp.task('startWebsocketServer', function() {
return nodemon({
script: './server/websocket/server.js',
watch: ['./server/websocket']
});
});

Related

Nodemon crashed when bound with gulp watch and restarted more than twice

I am trying to make my processes (webpack, nodemon-restart) work with a single gulp command. This works well enough. However, webpack builds only once if its task is tied to gulp's default task (together with nodemon), or embedded withing nodemon's gulp task.
Then I decided to tie both webpack build task and nodemon restart task to gulp's watch command and this works just the way I wanted, except that if you make changes and save them more than twice, the app nodemon crashed and prints this error in the console
"/home/nnanyielugo/Workspace/activity-calendar/node_modules/nodemon/lib/monitor/match.js:132
var rules = monitor.sort(function (a, b) {
^
TypeError: Cannot read property 'sort' of undefined"
As a solution, i tried to tie the webpack build task to the nodemon restart using the .on() method, and instead got an infinite loop of restarting an rebuilding (nodemon restarts first, webpack builds, nodemon restarts again, webpack rebuilds, and on and on).
Does anyone have a solution please?`
Here is a sample of my code `
var gulp = require('gulp'),
nodemon = require('gulp-nodemon'),
webpack = require('webpack-stream');
gulp.task('default', ['watch']);
gulp.task('webpack', function() {
return gulp.src('src/entry.js')
.pipe(webpack(require('./webpack.config.js')))
.pipe(gulp.dest('./public'));
});
gulp.task('nodemon', function () {
return nodemon({
script: 'app.js'
, ext: 'js html'
, env: { 'NODE_ENV': 'development' }
})
})
gulp.task('watch', function(){
gulp.watch(['./api/**/*.js', './server/**/*.js', './*.js'], ['webpack', 'nodemon']);
})`
I guess, your nodemon and gulp's watch task collides with each other. Either you should get ride of using nodemon and to rely upon gulp to start your application.
Or else, you can get rid of your gulp's watch task and add the relevant script in your nodemon's restart method like this,
nodemon({
// script goes here.
}).on('restart', your_reload_logic)
Hope this helps!

Node JS to load dotenv with forever

I would like to ask if anyone know how to run forever that can load .env file.
Currently if we run forever start app.js, process.env.foo become undefined.
TLDR, You need to add the --workingDir path to your cronjob line.
forever -c "node -r dotenv/config" --workingDir app-workdir-path start app.js
Many previous answers but none of them really solve this specific use case.
To run forever with dotenv you'll need to do two things.
First is we need to use dotenv's preload feature, meaning we need forever to pass a node parameter to the process. we can do it by using the -c COMMAND flag forever has.
The second thing is related to how the dotenv package works. here is snippet from the source code:
let dotenvPath = path.resolve(process.cwd(), '.env')
What does process.cwd() do?
The process.cwd() method is an inbuilt application programming interface of the process module which is used to get the current working directory of the node.js process.
Meaning dovenv package want's to load the .env file from the working directory. so to solve this issue we can use forever's --workingDir flag to specify the actual working directory of the process.
And the final command will look like this:
forever -c "node -r dotenv/config" --workingDir app-workdir-path start app.js
Where app-workdir-path is the absolute path to the project directory.
What worked for me was to specify the full path:
require('dotenv').config({ path: '/opt/api/.env' });
You can use dotenv package for this purpose. On your app entry, do this
require('dotenv').config({ path: '.env' })
If you have added .env file in root directory of your project then you can use like this
require('dotenv').config()
Or if you created your file .env with different location then in your code use
require('dotenv').config({path : '/your/path/.env'})
I found your question and had the same issue. I don't think dotenv works with forever - At least not that I was able to get working. However, I think there's a workaround that you could employ. I was able to specify environment variables on the command line preceding the forever command, and forever passed those environment variables to my node app.
~$ ENV=production forever start yourApp.js
For more information about specifying environment variables on the command line, checkout this Stack Overflow question.
I've had this issue with multiserver forever config.
You should include --workingDir parameter pointing to the root of your project directory in case you've included .env file in your root and using dotenv
Example:
Flexible config with minimum "hard coded" values
.env placed in root directory
"dotenv" used in form of dotenv.config()
Code for multiserver config in case of one server:
const fs = require('fs');
const path = require('path');
let foreverConfig = [
{
uid: 'scheduledJobsServer',
append: true,
watch: true,
script: 'scheduledJobsServer.js',
sourceDir: path.join(__dirname, '/server'),
workingDir: path.join(__dirname)
},
{
uid: 'mainServer',
append: true,
watch: true,
script: 'server.js',
sourceDir: path.join(__dirname, '/server'),
workingDir: path.join(__dirname)
}
];
try {
fs.writeFileSync(
path.join(__dirname, '/foreverConfig.json'),
JSON.stringify(foreverConfig),
{ encoding: 'utf8' }
);
let consoleMessage = 'Init script success';
console.log('\x1b[42m%s\x1b[0m', consoleMessage);
} catch (e) {
console.log('Init script error:', e);
process.exit(1);
}
Then run forever start foreverConfig.json
Sometimes you have to call the node script from another directory. For instance, when running cron jobs. Here is what you can do:
cd /path/to/script/ && /usr/bin/forever start /usr/bin/node script.js
Now the .env file will load.
The easiest command for me is
dotenv -e .env forever start build/index.js

docker node app always crashes on file change using nodemon

I am using the latest version of docker and the latest node image. I have a gulpfile that starts a nodemon process. I am using the --inspect flag to indicate I want to use the experimental chrome dev tool debugger. But when I make a file change it nodemon picks it up and restarts the process but crashes.
Here is my gulp task:
gulp.task('start:dev', done => {
let started = false;
nodemon({
script: path.join(__dirname, 'index.js'),
ext: 'js json',
nodeArgs: ['--inspect=0.0.0.0:9229'],
watch: path.join(__dirname, 'express'),
legacyWatch: true
})
.on('start', () => {
// to avoid nodemon being started multiple times
if (!started) {
setTimeout(() => done(), 100);
started = true;
}
});
});
And here is the error:
Starting inspector on 0.0.0.0:9229 failed: address already in use
If I change the --inspect flag to be --debug it works like a charm.
I am guessing is that the restart process is too fast for the --inspect to release its port. If I make another file change it does work and restarts normally. Probably since it had time to release the port.
I have tried using a delay on nodemon but I'd rather not. I would like quick restarts. And I have tried using to events, like, restart and exit, to wait for a few seconds and then restart the whole gulp task. But that was temperamental and again I want quick restarts without having to hack together something.
Right now I just switched back to --debug but that is deprecated in the latest V8. They are recommending to use --inspect.
Maybe the only way is to lock down my version of node?
Any suggestions?
There is an open issue addressing this problem.
The easiest workaround I found so far was using "signal": "SIGINT" in my nodemon.json thanks to this comment.
Just kill inspector and start inspector again
here is our team's solution in our package.json.
You had better kill inspector process and then restart inspector
"inspect": "kill-port --port 9229 && node --inspect=0.0.0.0:9229 build/startup.js",
"start_watch_inspect": `nodemon --delay 80ms --watch build/ build/startup.js --exec 'npm run inspect'`
Seems like this is related to:
https://github.com/remy/nodemon/issues/1492
My workaround is to run this before each restart: (in a makefile, gulp file etc...)
lsof -i -n | grep 9229 | awk '{print $2}' | xargs kill
** If put inside a Makefile remember to replace $ with $$ **

Gulp: Trouble setting browserSync and Watch

I'm learning Gulp and NPM and decided to test myself by using Browser-Sync with a PHP project I'm working on (using XAMPP). I know Browser-Sync doesnt work with PHP files, but I wanted to use it with my .css files (and later on perhaps add Sass).
I installed npm, Gulp, Gulp-watch and Browser Sync to my project's root directory and all seemed fine.
I then created a gulp.js file with the following:
var gulp = require('gulp'),
watch = require('gulp-watch'),
browserSync = require('browser-sync').create();
gulp.task('watch', function() {
browserSync.init({
server: {
baseDir: "./"
}
});
watch('css/*.css', function() {
browserSync.reload();
});
});
However, when I gulp watch a new browser window does open but just shows the Cannot GET / error.
Also, the URL shows http://localhost:3002/ rather than http://localhost:myproejct
I read this may have something to do with my baseDir so tried:
baseDir: ""
baseDir: "./"
baseDir: "../myproject"
Would anyone know what I've done wrong?
You are doing way more than is necessary to do what you want. You can just use browsersync as a proxy layer over the top of your hosted site.
See the following example from the docs
# Proxy a PHP app + serve static files & watch them
$ browser-sync start --proxy 'mylocal.dev' --serveStatic 'public' --files 'public'
I think this is what you will need, run it from the physical root of your site and replace mylocal.dev with your php server address
npm install browser-sync -g
browser-sync start --proxy 'mylocal.dev' --serveStatic 'css' --files 'css/*.css'
Your code works fine for me. Assuming your target HTML file works if opened in the browser manually: One common cause of the Cannot Get/ error is using an index file other than Browsersync's default expectation, index.html. Could that be the problem you're having? If you need a custom index file, you can set the index option:
browserSync.init({
server: {
baseDir: 'mybasedirectorypath',
index: 'notindex.html'
}
});
Fwiw, you can also do this more efficiently, and save yourself the weight of installing gulp-watch (this example adapted and simplified from this Browsersync docs example):
var gulp = require('gulp'),
browserSync = require('browser-sync').create();
gulp.task('watch', function() {
browserSync.init({
server: {
baseDir: './'
}
});
gulp.watch('css/*.css').on('change',browserSync.reload)
});
As for using a custom url, check out https://github.com/BrowserSync/browser-sync/issues/646 which has some solutions.

Gulp Watching Creates Infinite Loop Without Changing Files

Similar to other questions, in this very watered-down snippet, running the default gulp task (via npm start which runs gulp); this snippet creates an infinite loop running the scripts task over and over. Here is the gulpfile.js (literally the whole thing at the moment):
'use strict';
const gulp = require('gulp');
// COPY SCRIPTS TO BUILD FOLDER
gulp.task('scripts', function() {
return gulp.src('./scripts/**/*.js')
.pipe(gulp.dest('build/scripts'))
});
// WATCH FILES
gulp.task('watch', function() {
gulp.watch('./scripts/**/*.js', ['scripts']);
});
// DEFAULT
gulp.task('default', ['watch']);
The extra odd thing is that whether the build folder is built anew or not, the scripts task will be executed immediately after calling npm start! And the loop begins.
In case you're curious, here is the pasted (and only) scripts object in my package.json:
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1",
"start": "gulp"
},
The only other thing in my directory is a scripts folder with an app.js and an home.js file in it. Obviously once this task is run, the build folder is created (if it wasn't already there yet) and the two aforementioned files are copied into it.
You can see I'm only looking for scripts in the root directory's first level folder called scripts, so I shouldn't have an infinite loop by referencing changes on the same set of scripts. Also, even if I'm explicit, and point to exactly one particular file with a relative path such as ./scripts/home.js this still happens.
I'm anticipating being embarrassed, but I'm utterly confused.
A few things I've picked up on which could be causing some errors.
EDIT -
Try the watch plugin npm install --save-dev gulp-watch
// Try and declare your plugins like this for now.
var gulp = require('gulp'),
watch = require('gulp-watch');
// Provide a callback, cb
gulp.task('scripts', function(cb) {
// Dont use ./ on your src as watch can have a problem with this
return gulp.src('scripts/**/*.js')
.pipe(gulp.dest('./build/scripts'), cb); // call cb and dont forget ;
});
// remove ./ on watch
gulp.task('watch', function() {
gulp.watch('scripts/**/*.js', ['scripts']);
});
gulp.task('default', ['watch']);
So that is pretty weird behaviour but this should do the trick.
The only time I use ./ within gulp is on my dest.
Also just remember that gulpfile is just a JS so remember your semicolon, etc.
I cannot guarantee the resolution here, but I had a two variables that changed when this was resolved:
I upgraded my Parallels VM application (on an Apple PowerBook) from
version 10 -> 11.
I reinstalled Windows 10 using another license for a current version
(the previous one was a licensed dev or early release version).
My code, Node version, devDependencies and versions were identical.

Resources