npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

@gregtyler/grunt-contrib-watch

v1.1.0

Published

Run predefined tasks whenever watched file patterns are added, changed or deleted

Downloads

2

Readme

grunt-contrib-watch v1.0.0 Build Status: Linux Build Status: Windows

Run predefined tasks whenever watched file patterns are added, changed or deleted

Getting Started

If you haven't used Grunt before, be sure to check out the Getting Started guide, as it explains how to create a Gruntfile as well as install and use Grunt plugins. Once you're familiar with that process, you may install this plugin with this command:

npm install grunt-contrib-watch --save-dev

Once the plugin has been installed, it may be enabled inside your Gruntfile with this line of JavaScript:

grunt.loadNpmTasks('grunt-contrib-watch');

Watch task

Run this task with the grunt watch command.

Settings

There are a number of options available. Please review the minimatch options here. As well as some additional options as follows:

files

Type: String|Array

This defines what file patterns this task will watch. It can be a string or an array of files and/or minimatch patterns.

tasks

Type: String|Array

This defines which tasks to run when a watched file event occurs.

options.spawn

Type: Boolean
Default: true

Whether to spawn task runs in a child process. Setting this option to false speeds up the reaction time of the watch (usually 500ms faster for most) and allows subsequent task runs to share the same context. Not spawning task runs can make the watch more prone to failing so please use as needed.

Example:

watch: {
  scripts: {
    files: ['**/*.js'],
    tasks: ['jshint'],
    options: {
      spawn: false,
    },
  },
},

For backwards compatibility the option nospawn is still available and will do the opposite of spawn.

options.interrupt

Type: Boolean
Default: false

As files are modified this watch task will spawn tasks in child processes. The default behavior will only spawn a new child process per target when the previous process has finished. Set the interrupt option to true to terminate the previous process and spawn a new one upon later changes.

Example:

watch: {
  scripts: {
    files: '**/*.js',
    tasks: ['jshint'],
    options: {
      interrupt: true,
    },
  },
},

options.debounceDelay

Type: Integer
Default: 500

How long to wait before emitting events in succession for the same filepath and status. For example if your Gruntfile.js file was changed, a changed event will only fire again after the given milliseconds.

Example:

watch: {
  scripts: {
    files: '**/*.js',
    tasks: ['jshint'],
    options: {
      debounceDelay: 250,
    },
  },
},

options.interval

Type: Integer
Default: 100

The interval is passed to fs.watchFile. Since interval is only used by fs.watchFile and this watcher also uses fs.watch; it is recommended to ignore this option. Default is 100ms.

options.event

Type: String|Array
Default: 'all'

Specify the type of watch events that triggers the specified task. This option can be one or many of: 'all', 'changed', 'added' and 'deleted'.

Example:

watch: {
  scripts: {
    files: '**/*.js',
    tasks: ['generateFileManifest'],
    options: {
      event: ['added', 'deleted'],
    },
  },
},

options.reload

Type: Boolean
Default: false

By default, if Gruntfile.js is being watched, then changes to it will trigger the watch task to restart, and reload the Gruntfile.js changes. When reload is set to true, changes to any of the watched files will trigger the watch task to restart. This is especially useful if your Gruntfile.js is dependent on other files.

watch: {
  configFiles: {
    files: [ 'Gruntfile.js', 'config/*.js' ],
    options: {
      reload: true
    }
  }
}

options.forever

Type: Boolean
Default: true

This is only a task level option and cannot be configured per target. By default the watch task will duck punch grunt.fatal and grunt.warn to try and prevent them from exiting the watch process. If you don't want grunt.fatal and grunt.warn to be overridden set the forever option to false.

options.dateFormat

Type: Function

This is only a task level option and cannot be configured per target. By default when the watch has finished running tasks it will display the message Completed in 1.301s at Thu Jul 18 2013 14:58:21 GMT-0700 (PDT) - Waiting.... You can override this message by supplying your own function:

watch: {
  options: {
    dateFormat: function(time) {
      grunt.log.writeln('The watch finished in ' + time + 'ms at' + (new Date()).toString());
      grunt.log.writeln('Waiting for more changes...');
    },
  },
  scripts: {
    files: '**/*.js',
    tasks: 'jshint',
  },
},

options.atBegin

Type: Boolean
Default: false

This option will trigger the run of each specified task at startup of the watcher.

options.livereload

Type: Boolean|Number|Object
Default: false

Set to true or set livereload: 1337 to a port number to enable live reloading. Default and recommended port is 35729.

If enabled a live reload server will be started with the watch task per target. Then after the indicated tasks have run, the live reload server will be triggered with the modified files.

See also how to enable livereload on your HTML.

Example:

watch: {
  css: {
    files: '**/*.sass',
    tasks: ['sass'],
    options: {
      livereload: true,
    },
  },
},

Passing an object to livereload allows listening on a specific port and hostname/IP or over https connections (by specifying key and cert paths).

Example:

watch: {
  css: {
    files: '**/*.sass',
    tasks: ['sass'],
    options: {
      livereload: {
        host: 'localhost',
        port: 9000,
        key: grunt.file.read('path/to/ssl.key'),
        cert: grunt.file.read('path/to/ssl.crt')
        // you can pass in any other options you'd like to the https server, as listed here: http://nodejs.org/api/tls.html#tls_tls_createserver_options_secureconnectionlistener
      }
    },
  },
},

options.cwd

Type: String|Object
Default: process.cwd()

Ability to set the current working directory. Defaults to process.cwd(). Can either be a string to set the cwd to match files and spawn tasks or an object to set each independently. Such as:

options: {
  cwd: {
    files: 'match/files/from/here',
    spawn: 'but/spawn/files/from/here'
  }
}

To strip off a path before emitting events:

options: {
  cwd: {
    files: 'a/path',
    event: 'a/path'
  }
}

This will strip off a/path before emitting events. This option is useful for specifying the base directory to use with livereload.

options.livereloadOnError

Type: Boolean
Default: true

Option to prevent the livereload if the executed tasks encountered an error. If set to false, the livereload will only be triggered if all tasks completed successfully.

Examples

// Simple config to run jshint any time a file is added, changed or deleted
grunt.initConfig({
  watch: {
    files: ['**/*'],
    tasks: ['jshint'],
  },
});
// Advanced config. Run specific tasks when specific files are added, changed or deleted.
grunt.initConfig({
  watch: {
    gruntfile: {
      files: 'Gruntfile.js',
      tasks: ['jshint:gruntfile'],
    },
    src: {
      files: ['lib/*.js', 'css/**/*.scss', '!lib/dontwatch.js'],
      tasks: ['default'],
    },
    test: {
      files: '<%= jshint.test.src %>',
      tasks: ['jshint:test', 'qunit'],
    },
  },
});

Using the watch event

This task will emit a watch event when watched files are modified. This is useful if you would like a simple notification when files are edited or if you're using this task in tandem with another task. Here is a simple example using the watch event:

grunt.initConfig({
  watch: {
    scripts: {
      files: ['lib/*.js'],
    },
  },
});
grunt.event.on('watch', function(action, filepath, target) {
  grunt.log.writeln(target + ': ' + filepath + ' has ' + action);
});

The watch event is not intended for replacing the standard Grunt API for configuring and running tasks. If you're trying to run tasks from within the watch event you're more than likely doing it wrong. Please read configuring tasks.

Compiling Files As Needed

A very common request is to only compile files as needed. Here is an example that will only lint changed files with the jshint task:

grunt.initConfig({
  watch: {
    scripts: {
      files: ['lib/*.js'],
      tasks: ['jshint'],
      options: {
        spawn: false,
      },
    },
  },
  jshint: {
    all: {
      src: ['lib/*.js'],
    },
  },
});

// On watch events configure jshint:all to only run on changed file
grunt.event.on('watch', function(action, filepath) {
  grunt.config('jshint.all.src', filepath);
});

If you need to dynamically modify your config, the spawn option must be disabled to keep the watch running under the same context.

If you save multiple files simultaneously you may opt for a more robust method:

var changedFiles = Object.create(null);
var onChange = grunt.util._.debounce(function() {
  grunt.config('jshint.all.src', Object.keys(changedFiles));
  changedFiles = Object.create(null);
}, 200);
grunt.event.on('watch', function(action, filepath) {
  changedFiles[filepath] = action;
  onChange();
});

Live Reloading

Live reloading is built into the watch task. Set the option livereload to true to enable on the default port 35729 or set to a custom port: livereload: 1337.

The simplest way to add live reloading to all your watch targets is by setting livereload to true at the task level. This will run a single live reload server and trigger the live reload for all your watch targets:

grunt.initConfig({
  watch: {
    options: {
      livereload: true,
    },
    css: {
      files: ['public/scss/*.scss'],
      tasks: ['compass'],
    },
  },
});

You can also configure live reload for individual watch targets or run multiple live reload servers. Just be sure if you're starting multiple servers they operate on different ports:

grunt.initConfig({
  watch: {
    css: {
      files: ['public/scss/*.scss'],
      tasks: ['compass'],
      options: {
        // Start a live reload server on the default port 35729
        livereload: true,
      },
    },
    another: {
      files: ['lib/*.js'],
      tasks: ['anothertask'],
      options: {
        // Start another live reload server on port 1337
        livereload: 1337,
      },
    },
    dont: {
      files: ['other/stuff/*'],
      tasks: ['dostuff'],
    },
  },
});
Enabling Live Reload in Your HTML

Once you've started a live reload server you'll be able to access the live reload script. To enable live reload on your page, add a script tag before your closing </body> tag pointing to the livereload.js script:

<script src="//localhost:35729/livereload.js"></script>

Feel free to add this script to your template situation and toggle with some sort of dev flag.

Using Live Reload with the Browser Extension

Instead of adding a script tag to your page, you can live reload your page by installing a browser extension. Please visit how do I install and use the browser extensions for help installing an extension for your browser.

Once installed please use the default live reload port 35729 and the browser extension will automatically reload your page without needing the <script> tag.

Using Connect Middleware

Since live reloading is used when developing, you may want to disable building for production (and are not using the browser extension). One method is to use Connect middleware to inject the script tag into your page. Try the connect-livereload middleware for injecting the live reload script into your page.

Rolling Your Own Live Reload

Live reloading is made easy by the library tiny-lr. It is encouraged to read the documentation for tiny-lr. If you would like to trigger the live reload server yourself, simply POST files to the URL: http://localhost:35729/changed. Or if you rather roll your own live reload implementation use the following example:

// Create a live reload server instance
var lrserver = require('tiny-lr')();

// Listen on port 35729
lrserver.listen(35729, function(err) { console.log('LR Server Started'); });

// Then later trigger files or POST to localhost:35729/changed
lrserver.changed({body:{files:['public/css/changed.css']}});
Live Reload with Preprocessors

Any time a watched file is edited with the livereload option enabled, the file will be sent to the live reload server. Some edited files you may desire to have sent to the live reload server, such as when preprocessing (sass, less, coffeescript, etc). As any file not recognized will reload the entire page as opposed to just the css or javascript.

The solution is to point a livereload watch target to your destination files:

grunt.initConfig({
  sass: {
    dev: {
      src: ['src/sass/*.sass'],
      dest: 'dest/css/index.css',
    },
  },
  watch: {
    sass: {
      // We watch and compile sass files as normal but don't live reload here
      files: ['src/sass/*.sass'],
      tasks: ['sass'],
    },
    livereload: {
      // Here we watch the files the sass task will compile to
      // These files are sent to the live reload server after sass compiles to them
      options: { livereload: true },
      files: ['dest/**/*'],
    },
  },
});

FAQs

How do I fix the error EMFILE: Too many opened files.?

This is because of your system's max opened file limit. For OSX the default is very low (256). Temporarily increase your limit with ulimit -n 10480, the number being the new max limit.

In some versions of OSX the above solution doesn't work. In that case try launchctl limit maxfiles 10480 10480 and restart your terminal. See here.

Can I use this with Grunt v0.3?

[email protected] is compatible with Grunt v0.3 but it is highly recommended to upgrade Grunt instead.

Why is the watch devouring all my memory/cpu?

Likely because of an enthusiastic pattern trying to watch thousands of files. Such as '**/*.js' but forgetting to exclude the node_modules folder with '!**/node_modules/**'. Try grouping your files within a subfolder or be more explicit with your file matching pattern.

Another reason if you're watching a large number of files could be the low default interval. Try increasing with options: { interval: 5007 }. Please see issues #35 and #145 for more information.

Why spawn as child processes as a default?

The goal of this watch task is as files are changed, run tasks as if they were triggered by the user himself or herself. Each time a user runs grunt a process is spawned and tasks are ran in succession. In an effort to keep the experience consistent and continually produce expected results, this watch task spawns tasks as child processes by default.

Sandboxing task runs also allows this watch task to run more stable over long periods of time. As well as more efficiently with more complex tasks and file structures.

Spawning does cause a performance hit (usually 500ms for most environments). It also cripples tasks that rely on the watch task to share the context with each subsequent run (i.e., reload tasks). If you would like a faster watch task or need to share the context please set the spawn option to false. Just be aware that with this option enabled, the watch task is more prone to failure.

How can I have the browser reload for files listed in a task?

Instead of restarting your server each time a static file is changed, start a static web server using (grunt-contrib-connect)[https://github.com/gruntjs/grunt-contrib-connect].

You'll have the connect web server on separate port ex: port 9000 from your main server. When the 'livereload' option is enabled for 'watch' tasks, it will handle triggering the live reload server for each tasks and when files are modified, which then server back to main server ex: 3000. The main server must include a script tag or a browser extension to the livereload server in order for the browser automatically.

Release History

  • 2016-03-12   v1.0.0   Updated tiny-lr, gaze, async and lodash dependencies. Fix endless loop issue with atBegin/nospawn. Expose hostname parameter of tiny-lr. Support cwd.event to emit events relative to path. Removed peerDependencies setting.
  • 2014-03-19   v0.6.1   Fix for watch targets named "default".
  • 2014-03-11   v0.6.0   Clear changed files after triggering live reload to ensure they're only triggered once. cwd option now accepts separate settings for files and spawn. Fix to make interrupt work more than once. Enable live reload over HTTPS. Print newline after initial 'Waiting...'. Remove deprecated grunt.util libs. Add reload option to specify files other than Gruntfile files to reload. Update to [email protected]. Use a fork of tiny-lr (which has quiter operation, support for HTTPS and Windows path fixes). Add livereloadOnError, which if set to false will not trigger live reload if there is an error.
  • 2013-08-25   v0.5.3   Fixed for live reload missing files.
  • 2013-08-16   v0.5.2   Fixed issue running tasks after gruntfile is reloaded. Ignores empty file paths.
  • 2013-07-20   v0.5.1   Fixed issue with options resetting.
  • 2013-07-18   v0.5.0   Added target name to watch event. Added atBegin option to run tasks when watcher starts. Changed nospawn option to spawn (nospawn still available for backwards compatibility). Moved libs/vars into top scope to prevent re-init. Bumped Gaze version to ~0.4. Re-grab task/target options upon each task run. Add dateFormat option to override the date/time output upon completion.
  • 2013-05-27   v0.4.4   Remove gracefully closing SIGINT. Not needed and causes problems for Windows. Ensure tasks are an array to not conflict with cliArgs.
  • 2013-05-11   v0.4.3   Only group changed files per target to send correct files to live reload.
  • 2013-05-09   v0.4.2   Fix for closing watchers.
  • 2013-05-09   v0.4.1   Removed "beep" notification. Tasks now optional with livereload option. Reverted "run again" with interrupt off to fix infinite recursion issue. Watchers now close more properly on task run.
  • 2013-05-03   v0.4.0   Option livereload to start live reload servers. Will reload a Gruntfile before running tasks if Gruntfile is modified. Option event to only trigger watch on certain events. Refactor watch task into separate task runs per target. Option forever to override grunt.fatal/warn to help keeping the watch alive with nospawn enabled. Emit a beep upon complete. Logs all watched files with verbose flag set. If interrupt is off, will run the tasks once more if watch triggered during a previous task run. tasks property is optional for use with watch event. Watchers properly closed when exiting.
  • 2013-02-28   v0.3.1   Fix for top level options.
  • 2013-02-27   v0.3.0   nospawn option added to run tasks without spawning as child processes. Watch emits 'watch' events upon files being triggered with grunt.event. Completion time in seconds and date/time shown after tasks ran. Negate file patterns fixed. Tasks debounced individually to handle simultaneous triggering for multiple targets. Errors handled better and viewable with --stack CLI option. Code complexity reduced making the watch task code easier to read.
  • 2013-02-15   v0.2.0   First official release for Grunt 0.4.0.
  • 2013-01-18   v0.2.0rc7   Updating grunt/gruntplugin dependencies to rc6. Changing in-development grunt/gruntplugin dependency versions from tilde version ranges to specific versions.
  • 2013-01-09   v0.2.0rc5   Updating to work with grunt v0.4.0rc5.
  • 2012-12-15   v0.2.0a   Conversion to grunt v0.4 conventions. Remove Node.js v0.6 and grunt v0.3 support. Allow watch task to be renamed. Use grunt.util.spawn "grunt" option. Updated to [email protected], forceWatchMethod option removed.
  • 2012-11-01   v0.1.4   Prevent watch from spawning duplicate watch tasks.
  • 2012-10-28   v0.1.3   Better method to spawn the grunt bin. Bump gaze to v0.2.0. Better handles some events and new option forceWatchMethod. Only support Node.js >= v0.8.
  • 2012-10-17   v0.1.2   Only spawn a process per task one at a time. Add interrupt option to cancel previous spawned process. Grunt v0.3 compatibility changes.
  • 2012-10-16   v0.1.1   Fallback to global grunt bin if local doesn't exist. Fatal if bin cannot be found. Update to gaze 0.1.6.
  • 2012-10-08   v0.1.0   Release watch task. Remove spawn from helper. Run on Grunt v0.4.

Task submitted by Kyle Robinson Young

This file was generated on Fri Mar 18 2016 19:24:09.