Simple monitor script for use during development of a node.js app.
monitor development restart autoload reload terminal


Project Name nodemon Project Url
InceptionYear 2011-02-03 17:03:46 更新时间 2020-05-14 19:33:05
IssueManagement Licenses MIT
仓库地址 git+ 用户数 642
Node Engine >=8.10.0 文件大小 33.8 KB
install commitmsg coverage lint :spec test spec postspec clean web semantic-release prepush killall postinstall


Nodemon Logo

# 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. [![NPM version](]( [![Travis Status](]( [![Backers on Open Collective](](#backers) [![Sponsors on Open Collective](](#sponsors) # Installation Either through cloning with git or by using [npm]( (the recommended way): ```bash npm install -g nodemon ``` And nodemon will be installed globally to your system path. You can also install nodemon as a development dependency: ```bash npm install --save-dev nodemon ``` With a local installation, nodemon will not be available in your system path. 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: ```bash nodemon [your node app] ``` For CLI options, use the `-h` (or `--help`) argument: ```bash nodemon -h ``` Using nodemon is simple, if my application accepted a host and port as the arguments, I would start it as so: ```bash 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. If no script is given, nodemon will test for a `package.json` file and if found, will run the file associated with the *main* property ([ref]( You can also pass the `inspect` flag to node through the command line as you would normally: ```bash 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. 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 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 Whilst nodemon is running, if you need to manually restart your application, instead of stopping and restart nodemon, you can type `rs` with a carriage return, and nodemon will restart your process. ## Config files 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 ` 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: ```json { "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 out of the box support for processing scripts. A further example of options can be seen in []( ### package.json 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`: ```json { "name": "nodemon", "homepage": "", "...": "... 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 Please see [doc/](doc/ ## Using nodemon as child process Please see [doc/](doc/ ## Running non-node scripts 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`: ```bash nodemon --exec "python -v" ./ ``` Now nodemon will run `` 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 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: ```json { "execMap": { "pl": "perl" } } ``` Now running the following, nodemon will know to use `perl` as the executable: ```bash nodemon ``` 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 in to the project so that nodemon supports it by default, by changing [default.js]( and sending a pull request. ## Monitoring multiple directories 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: ```bash 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 in explicitly including sub-directories. Don't use unix globbing to pass multiple directories, e.g `--watch ./lib/*`, it won't work. You need a `--watch` flag per directory watched. ## Specifying extension watch list By default, nodemon looks for files with the `.js`, `.mjs`, `.coffee`, `.litcoffee`, and `.json` extensions. If you use the `--exec` option and monitor `` nodemon will monitor files with the extension of `.py`. However, you can specify your own list with the `-e` (or `--ext`) switch like so: ```bash 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 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: ```bash nodemon --ignore lib/ --ignore tests/ ``` Or specific files can be ignored: ```bash nodemon --ignore lib/app.js ``` Patterns can also be ignored (but be sure to quote the arguments): ```bash nodemon --ignore 'lib/*.js' ``` 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 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: ```bash nodemon -L ``` Though this should be a last resort as it will poll every file it can find. ## Delaying restarting 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: ```bash nodemon --delay 10 server.js ``` For more precision, milliseconds can be specified. Either as a float: ```bash nodemon --delay 2.5 server.js ``` Or using the time specifier (ms): ```bash 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: ```bash nodemon --delay 2.5 { "delay": "2500" } ``` ## Gracefully reloading down your script It is possible to have nodemon send any signal that you specify to your application. ```bash nodemon --signal SIGHUP server.js ``` Your application can handle the signal as follows. ```js process.once("SIGHUP", function () { reloadSomeConfiguration(); }) ``` Please note that nodemon will send this signal to every process in the process tree. If you are using `cluster`, then each workers (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`. ```js 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 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: ```js process.once('SIGUSR2', function () { gracefulShutdown(function () { process.kill(, 'SIGUSR2'); }); }); ``` 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 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: ```json { "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 ```js 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 Check out the [gulp-nodemon]( plugin to integrate nodemon with the rest of your project's gulp workflow. ## Using nodemon in your Grunt workflow Check out the [grunt-nodemon]( plugin to integrate nodemon with the rest of your project's grunt workflow. ## Pronunciation > 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 - 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 has sprawled beyond where I'm completely happy, but perhaps it can be reduced a little one day. ## FAQ See the [FAQ]( and please add your own questions if you think they would help others. ## Backers Thank you to all [our backers](! ???? [![nodemon backers](]( ## Sponsors Support this project by becoming a sponsor. Your logo will show up here with a link to your website. [Sponsor this project today ❤️]( []( []( # License MIT [](


GroupId ArtifactID Version 引用量
Paul Miller chokidar 3.4.2 8787
TJ Holowaychuk debug 4.2.0 33676
Mark Wubben ignore-by-default 2.0.0 33
Isaac Z. Schlueter minimatch 3.0.4 3314
Remy Sharp pstree.remy 1.1.8 15
adam_baldwin semver 7.2.3 21876
Sindre Sorhus supports-color 7.2.0 1107
Isaac Z. Schlueter touch 3.1.0 652
Remy Sharp undefsafe 2.0.3 35
Sindre Sorhus update-notifier 5.0.0 3743


GroupId ArtifactID Version 引用量
Mario Nebl @commitlint/cli 11.0.0 11818
Mario Nebl @commitlint/config-angular 11.0.0 1313
Caolan McMahon async 3.2.0 30686
Jeremy Ashkenas coffee-script 1.12.7 17
Typicode husky 4.3.0 56340
Krishnan Anantheswaran istanbul 0.4.5 223
Marat Dulin jscs 3.0.7 4207
Thorsten Lorenz proxyquire 2.1.3 5239
Stephan Bönnemann semantic-release 17.1.2 18087
TJ Holowaychuk should 13.2.3 79