nodemon Documentation

1. Project Overview & Quickstart (remy/nodemon) Copy Chapter

File: README.md Copy Chapter

nodemon

nodemon is a tool that helps develop Node.js based applications by automatically restarting the node application when file changes in the directory are detected.

nodemon does not require any additional changes to your code or method of development. nodemon is a replacement wrapper for node. To use nodemon, replace the word node on the command line when executing your script.

Installation

Either through cloning with git or by using npm (the recommended way):

npm install nodemon # or using yarn: yarn global add nodemon

And nodemon will be installed globally to your system path.

You can also install nodemon as a development dependency:

npm install --save-dev nodemon # or using yarn: yarn add nodemon -D

With a local installation, nodemon will not be available in your system path, so you can't use it directly from the command line. Instead, the local installation of nodemon can be run by calling it from within an npm script (such as npm start) or using npx nodemon.

Usage

nodemon wraps your application, so you can pass all the arguments you would normally pass to your app:

nodemon [your node app]

For CLI options, use the -h (or --help) argument:

nodemon -h

Using nodemon is simple, if my application accepted a host and port as the arguments, I would start it like so:

nodemon ./server.js localhost 8080

Any output from this script is prefixed with [nodemon], otherwise all output from your application, errors included, will be echoed out as expected.

You can also pass the inspect flag to node through the command line as you would normally:

nodemon --inspect ./server.js 80

If you have a package.json file for your app, you can omit the main script entirely and nodemon will read the package.json for the main property and use that value as the app (ref).

nodemon will also search for the scripts.start property in package.json (as of nodemon 1.1.x).

Also check out the FAQ or issues for nodemon.

Automatic re-running Copy Chapter

nodemon was originally written to restart hanging processes such as web servers, but now supports apps that cleanly exit. If your script exits cleanly, nodemon will continue to monitor the directory (or directories) and restart the script if there are any changes.

Manual restarting Copy Chapter

Whilst nodemon is running, if you need to manually restart your application, instead of stopping and restarting nodemon, you can type rs with a carriage return, and nodemon will restart your process.

Config files Copy Chapter

nodemon supports local and global configuration files. These are usually named nodemon.json and can be located in the current working directory or in your home directory. An alternative local configuration file can be specified with the --config <file> option.

The specificity is as follows, so that a command line argument will always override the config file settings:

• command line arguments
• local config
• global config

A config file can take any of the command line arguments as JSON key values, for example:

{
  "verbose": true,
  "ignore": ["*.test.js", "**/fixtures/**"],
  "execMap": {
    "rb": "ruby",
    "pde": "processing --sketch={{pwd}} --run"
  }
}

The above nodemon.json file might be my global config so that I have support for ruby files and processing files, and I can run nodemon demo.pde and nodemon will automatically know how to run the script even though there is no out-of-the-box support for processing scripts.

A further example of options can be seen in sample-nodemon.md

package.json Copy Section

If you want to keep all your package configurations in one place, nodemon supports using package.json for configuration.
Specify the config in the same format as you would for a config file but under nodemonConfig in the package.json file, for example, take the following package.json:

{
  "name": "nodemon",
  "homepage": "http://nodemon.io",
  "...": "... other standard package.json values",
  "nodemonConfig": {
    "ignore": ["**/test/**", "**/docs/**"],
    "delay": 2500
  }
}

Note that if you specify a --config file or provide a local nodemon.json any package.json config is ignored.

This section needs better documentation, but for now you can also see nodemon --help config (also here).

Using nodemon as a module Copy Chapter

Please see doc/requireable.md

Using nodemon as child process Copy Chapter

Please see doc/events.md

Running non-node scripts Copy Chapter

nodemon can also be used to execute and monitor other programs. nodemon will read the file extension of the script being run and monitor that extension instead of .js if there's no nodemon.json:

nodemon --exec "python -v" ./app.py

Now nodemon will run app.py with python in verbose mode (note that if you're not passing args to the exec program, you don't need the quotes), and look for new or modified files with the .py extension.

Default executables Copy Section

Using the nodemon.json config file, you can define your own default executables using the execMap property. This is particularly useful if you're working with a language that isn't supported by default by nodemon.

To add support for nodemon to know about the .pl extension (for Perl), the nodemon.json file would add:

{
  "execMap": {
    "pl": "perl"
  }
}

Now running the following, nodemon will know to use perl as the executable:

nodemon script.pl

It's generally recommended to use the global nodemon.json to add your own execMap options. However, if there's a common default that's missing, this can be merged into the project so that nodemon supports it by default, by changing default.js and sending a pull request.

Monitoring multiple directories Copy Chapter

By default nodemon monitors the current working directory. If you want to take control of that option, use the --watch option to add specific paths:

nodemon --watch app --watch libs app/server.js

Now nodemon will only restart if there are changes in the ./app or ./libs directory. By default nodemon will traverse sub-directories, so there's no need to explicitly include sub-directories.

Nodemon also supports unix globbing, e.g --watch './lib/*'. The globbing pattern must be quoted. For advanced globbing, see picomatch documentation, the library that nodemon uses through chokidar (which in turn uses it through anymatch).

Specifying extension watch list Copy Chapter

By default, nodemon looks for files with the .js, .mjs, .coffee, .litcoffee, and .json extensions. If you use the --exec option and monitor app.py nodemon will monitor files with the extension of .py. However, you can specify your own list with the -e (or --ext) switch like so:

nodemon -e js,pug

Now nodemon will restart on any changes to files in the directory (or subdirectories) with the extensions .js, .pug.

Ignoring files Copy Chapter

By default, nodemon will only restart when a .js JavaScript file changes. In some cases you will want to ignore some specific files, directories or file patterns, to prevent nodemon from prematurely restarting your application.

This can be done via the command line:

nodemon --ignore lib/ --ignore tests/

Or specific files can be ignored:

nodemon --ignore lib/app.js

Patterns can also be ignored (but be sure to quote the arguments):

nodemon --ignore 'lib/*.js'

Important the ignore rules are patterns matched to the full absolute path, and this determines how many files are monitored. If using a wild card glob pattern, it needs to be used as ** or omitted entirely. For example, nodemon --ignore '**/test/**' will work, whereas --ignore '*/test/*' will not.

Note that by default, nodemon will ignore the .git, node_modules, bower_components, .nyc_output, coverage and .sass-cache directories and add your ignored patterns to the list. If you want to indeed watch a directory like node_modules, you need to override the underlying default ignore rules.

Application isn't restarting Copy Chapter

In some networked environments (such as a container running nodemon reading across a mounted drive), you will need to use the legacyWatch: true which enables Chokidar's polling.

Via the CLI, use either --legacy-watch or -L for short:

nodemon -L

Though this should be a last resort as it will poll every file it can find.

Delaying restarting Copy Chapter

In some situations, you may want to wait until a number of files have changed. The timeout before checking for new file changes is 1 second. If you're uploading a number of files and it's taking some number of seconds, this could cause your app to restart multiple times unnecessarily.

To add an extra throttle, or delay restarting, use the --delay command:

nodemon --delay 10 server.js

For more precision, milliseconds can be specified. Either as a float:

nodemon --delay 2.5 server.js

Or using the time specifier (ms):

nodemon --delay 2500ms server.js

The delay figure is number of seconds (or milliseconds, if specified) to delay before restarting. So nodemon will only restart your app the given number of seconds after the last file change.

If you are setting this value in nodemon.json, the value will always be interpreted in milliseconds. E.g., the following are equivalent:

nodemon --delay 2.5

{
  "delay": 2500
}

Gracefully reloading your script Copy Chapter

It is possible to have nodemon send any signal that you specify to your application.

nodemon --signal SIGHUP server.js

Your application can handle the signal as follows.

process.on("SIGHUP", function () {
  reloadSomeConfiguration();
  process.kill(process.pid, "SIGTERM");
})

Please note that nodemon will send this signal to every process in the process tree.

If you are using cluster, then each worker (as well as the master) will receive the signal. If you wish to terminate all workers on receiving a SIGHUP, a common pattern is to catch the SIGHUP in the master, and forward SIGTERM to all workers, while ensuring that all workers ignore SIGHUP.

if (cluster.isMaster) {
  process.on("SIGHUP", function () {
    for (const worker of Object.values(cluster.workers)) {
      worker.process.kill("SIGTERM");
    }
  });
} else {
  process.on("SIGHUP", function() {})
}

Controlling shutdown of your script Copy Chapter

nodemon sends a kill signal to your application when it sees a file update. If you need to clean up on shutdown inside your script you can capture the kill signal and handle it yourself.

The following example will listen once for the SIGUSR2 signal (used by nodemon to restart), run the clean up process and then kill itself for nodemon to continue control:

// important to use `on` and not `once` as nodemon can re-send the kill signal
process.on('SIGUSR2', function () {
  gracefulShutdown(function () {
    process.kill(process.pid, 'SIGTERM');
  });
});

Note that the process.kill is only called once your shutdown jobs are complete. Hat tip to Benjie Gillam for writing this technique up.

Triggering events when nodemon state changes Copy Chapter

If you want growl like notifications when nodemon restarts or to trigger an action when an event happens, then you can either require nodemon or add event actions to your nodemon.json file.

For example, to trigger a notification on a Mac when nodemon restarts, nodemon.json looks like this:

{
  "events": {
    "restart": "osascript -e 'display notification \"app restarted\" with title \"nodemon\"'"
  }
}

A full list of available events is listed on the event states wiki. Note that you can bind to both states and messages.

Pipe output to somewhere else Copy Chapter

nodemon({
  script: ...,
  stdout: false // important: this tells nodemon not to output to console
}).on('readable', function() { // the `readable` event indicates that data is ready to pick up
  this.stdout.pipe(fs.createWriteStream('output.txt'));
  this.stderr.pipe(fs.createWriteStream('err.txt'));
});

Using nodemon in your gulp workflow Copy Chapter

Check out the gulp-nodemon plugin to integrate nodemon with the rest of your project's gulp workflow.

Using nodemon in your Grunt workflow Copy Chapter

Check out the grunt-nodemon plugin to integrate nodemon with the rest of your project's grunt workflow.

Pronunciation Copy Chapter

nodemon, is it pronounced: node-mon, no-demon or node-e-mon (like pokémon)?

Well...I've been asked this many times before. I like that I've been asked this before. There's been bets as to which one it actually is.

The answer is simple, but possibly frustrating. I'm not saying (how I pronounce it). It's up to you to call it as you like. All answers are correct :)

Design principles Copy Chapter

• Fewer flags is better
• Works across all platforms
• Fewer features
• Let individuals build on top of nodemon
• Offer all CLI functionality as an API
• Contributions must have and pass tests

Nodemon is not perfect, and CLI arguments have sprawled beyond where I'm completely happy, but perhaps they can be reduced a little one day.

FAQ Copy Chapter

See the FAQ and please add your own questions if you think they would help others.

Backers Copy Chapter

Thank you to all our backers! 🙏

Sponsors Copy Chapter

Support this project by becoming a sponsor. Your logo will show up here with a link to your website. Sponsor this project today ❤️

Please note that links to the sponsors above are not direct endorsements nor affiliated with any of contributors of the nodemon project.

License

MIT http://rem.mit-license.org

File: doc/arch.md Copy Chapter

nodemon code arch

CLI -> parser -> nodemon options -> rules

rules -> configure -> watch -> start process

CLI examples Copy Chapter

Watch src but only *.js and *.coffee

nodemon --watch src/ -e js,coffee app.js

Parsed to:

{
  watch: ['src/'],
  ignore: [],
  script: 'app.js'
  options: {
    extensions: ['js', 'coffee'],
    exec: 'node'
  }
}

Watch with no args:

nodemon

Parsed to (assuming a package.json or index.js is found):

{
  watch: [], // meaning all subdirectories
  ignore: [],
  script: 'index.js',
  options: {
    extensions: ['js'],
    exec: 'node'
  }
}

File: doc/events.md Copy Chapter

Events

nodemon will emit events based on the child process.

Commands Copy Chapter

• restart
• config:update
• quit

States Copy Chapter

• start - child process has started
• crash - child process has crashed (nodemon will not emit exit)
• exit - child process has cleanly exited (i.e. no crash)
• restart([ array of files triggering the restart ]) - child process has restarted
• config:update - nodemon's config has changed

Messages Copy Chapter

• log({ type, message (plain text log), colour (colour coded log) }) - logging from nodemon (not the child process)
• stdout - the stdout stream from the child process
• stderr - the stderr stream from the child process
• readable - stdout and stderr streams are ready (example)

Note that if you want to suppress the normal stdout & stderr of the child, in favour
of processing the stream manually using the stdout/stderr nodemon events, pass
nodemon the option of stdout: false.

Using nodemon events Copy Chapter

If nodemon is required, events can be bound and emitted on the nodemon object:

var nodemon = require('nodemon');

nodemon({ script: 'app.js' }).on('start', function () {
  console.log('nodemon started');
}).on('crash', function () {
  console.log('script crashed for some reason');
});

// force a restart
nodemon.emit('restart');

// force a quit
nodemon.emit('quit');

Using nodemon as child process Copy Chapter

If nodemon is a spawned process, then the child (nodemon) will emit message
events whereby the event argument contains the event type, and instead of
emitting events, you send the command:

// using `spawn` as example, can use other functions like `fork`, etc
// https://nodejs.org/api/child_process.html
const { spawn } = require('child_process');

function spawnNodemon() {
  const cp = spawn('nodemon', ['path/to/file.js', '--watch', 'path/to/watch'], {
    // the important part is the 4th option 'ipc'
    // this way `process.send` will be available in the child process (nodemon)
    // so it can communicate back with parent process (through `.on()`, `.send()`)
    // https://nodejs.org/api/child_process.html#child_process_options_stdio
    stdio: ['pipe', 'pipe', 'pipe', 'ipc'],
  });

  return cp;
}

var app = spawnNodemon();

app.on('message', function (event) {
  if (event.type === 'start') {
    console.log('nodemon started');
  } else if (event.type === 'crash') {
    console.log('script crashed for some reason');
  }
});

// force a restart
app.send('restart');

// force a quit
app.send('quit');

Note that even though the child will still emit a message event whose type is
exit, it makes more sense to listen to the actual exit event on the child:

app.on('exit', function () {
  console.log('nodemon quit');
});

File: doc/option-parsing-logic.md Copy Chapter

Option parsing logic

1. Read all CLI arguments
2. Load local config
3. Load global config
4. Try backup: package.main
5. Try backup: package.start
6. Try index.js

File: doc/requireable.md Copy Chapter

Nodemon as a required module

Nodemon (as of 1.0.0) also works as a required module. At present, you can only require nodemon into your project once (as there are static config variables), but you can re-run with new settings for a different application to monitor.

By requiring nodemon, you can extend its functionality. Below is a simple example of using nodemon in your project:

var nodemon = require('nodemon');

nodemon({
  script: 'app.js',
  ext: 'js json'
});

nodemon.on('start', function () {
  console.log('App has started');
}).on('quit', function () {
  console.log('App has quit');
  process.exit();
}).on('restart', function (files) {
  console.log('App restarted due to: ', files);
});

Nodemon will emit a number of events by default, and when in verbose mode will also emit a log event (which matches what the nodemon cli tool echoes).

Arguments Copy Chapter

The nodemon function takes either an object (that matches the nodemon config) or can take a string that matches the arguments that would be used on the command line:

var nodemon = require('nodemon');

nodemon('-e "js json" app.js');

Methods & Properties Copy Chapter

The nodemon object also has a few methods and properties. Some are exposed to help with tests, but have been listed here for completeness:

Event handling Copy Section

This is the event emitter bus that exists inside nodemon exposed at the top level module (i.e. it's the events api):

• nodemon.on(event, fn)
• nodemon.addListener(event, fn)
• nodemon.once(event, fn)
• nodemon.emit(event)
• nodemon.removeAllListeners([event])

Note: there's no removeListener (happy to take a pull request if it's needed).

Test utilities Copy Section

• nodemon.reset() - reverts nodemon's internal state to a clean slate
• nodemon.config - a reference to the internal config nodemon uses

File: doc/rules.md Copy Chapter

Rules

Given a nodemon.json file that contains:

{
  "ignore": ["*.coffee"],
  "watch": ["server/*.coffee", "test/"]
}

Then nodemon detects changes, but what causes nodemon to restart? The ignored files or the watched files? Which wins?

const files = ['server/foo.coffee', 'server/app.js'];

// afterIgnore = ['server/app.js'] now since foo.coffee matches *.coffee
const afterIgnore = files.filter(applyIgnore);

// watch = ['server/foo.coffee'] as it's under the watch
const watched = files.filter(applyWatch);

What about:

const files = ['test/app.js', 'test/app.coffee'];

// afterIgnore = ['test/app.js'] now since test/app.coffee matches *.coffee
const afterIgnore = files.filter(applyIgnore);

// watch.length = 2 as watch implies test/*.*
const watched = files.filter(applyWatch);

File: doc/sample-nodemon.md Copy Chapter

Sample nodemon.json

Here is an example (of a contrived) nodemon.json file:

{
  "restartable": "rs",
  "ignore": [
    ".git",
    "node_modules/**/node_modules"
  ],
  "verbose": true,
  "execMap": {
    "js": "node --harmony"
  },
  "events": {
    "restart": "osascript -e 'display notification \"App restarted due to:\n'$FILENAME'\" with title \"nodemon\"'"
  },
  "watch": [
    "test/fixtures/",
    "test/samples/"
  ],
  "env": {
    "NODE_ENV": "development"
  },
  "ext": "js,json"
}

Note that the ignore used is nodemon's default ignore rule. The complete defaults can be seen here: defaults.js.

2. Official Technical Reference & Guides (remy/docs) Copy Chapter

Snyk Documentation

Preview url: https://snyk.github.io/docs/

Getting set up Copy Chapter

1. Pull down the repo
2. In the command line, navigate to the repo's folder and run bundle install
3. If there are no errors, run jekyll serve
4. Go to http://localhost:4000/docs/ in your browser

Check out the Markdown-cheatsheet for how to write content.

Saving drafts Copy Section

If you want to preview a file but not let the changes show on production, add this line to the YAML front-matter:

---
draft: true
---

This will add a "draft" label and background colour.

Hide a title Copy Section

To not show the title (such as on a landing section), add this line to the YAML front-matter:

---
title: ""
---

Add inline code Copy Section

For inline code, such as a word, use a single backtick.

Add code blocks Copy Section

To wrap some code in a code block, use 3 backticks before and after the text.