chokidar vs filewatcher vs gaze vs node-watch vs sane vs watch vs watchpack
Node.js 文件监听方案选型与架构对比
chokidarfilewatchergazenode-watchsanewatchwatchpack类似的npm包:

Node.js 文件监听方案选型与架构对比

这些库都旨在解决 Node.js 原生 fs.watchfs.watchFile 在不同操作系统上行为不一致的问题。它们提供了统一的事件接口(如 add, change, unlink),支持递归监听目录,并处理了底层文件系统的边缘情况。对于需要实时响应文件变动的工具(如构建系统、热重载服务器、同步工具),选择合适的监听库至关重要。

npm下载趋势

3 年

GitHub Stars 排名

统计详情

npm包名称
下载量
Stars
大小
Issues
发布时间
License
chokidar012,12082.1 kB416 个月前MIT
filewatcher054-510 年前MIT
gaze01,154-688 年前MIT
node-watch034226.1 kB83 年前MIT
sane0388-345 年前MIT
watch01,282-599 年前Apache-2.0
watchpack039795.7 kB104 个月前MIT

Node.js 文件监听方案深度对比:Chokidar, Watchpack 与其他

在 Node.js 生态中,监听文件系统变化是构建工具、开发服务器和同步脚本的核心需求。虽然 Node 原生提供了 fs.watch,但它在不同操作系统(Windows, macOS, Linux)上的行为差异巨大,且经常丢失事件。为了解决这些问题,社区涌现了多个封装库。本文将深入对比 chokidar, watchpack, node-watch 以及几个已逐渐退场的老牌库。

🏗️ 核心架构与实现原理

chokidar 是目前的行业标准。它在底层根据操作系统选择不同的策略:在 macOS 上使用 fsevents 原生绑定以获得高性能,在其他系统上回退到 fs.watch。它处理了原生 API 的许多边缘情况,比如目录重命名和原子写入。

// chokidar: 统一的事件接口
const chokidar = require('chokidar');
const watcher = chokidar.watch('src', {
  ignored: /node_modules/,
  persistent: true
});

watcher.on('change', path => console.log(`File ${path} has been changed`));

watchpack 是 Webpack 团队专门为构建工具设计的。它不直接暴露底层事件,而是关注“文件是否安全”和“目录时间戳”。它支持聚合事件,避免在大量文件同时变更时(如 git checkout)触发数千次回调。

// watchpack: 针对构建优化的监听
const Watchpack = require('watchpack');
const wp = new Watchpack({
  aggregateTimeout: 1000
});

wp.watch([], ['src'], Date.now() - 10000);
wp.on('aggregated', (changes, removals) => {
  console.log('Changes:', changes);
});

node-watch 坚持纯 JavaScript 实现,不依赖任何原生模块。这使得它在跨平台编译或某些 Serverless 环境中更具优势,尽管在 macOS 上性能可能略低于使用 fsevents 的方案。

// node-watch: 纯 JS 实现
const watch = require('node-watch');

watch('src', { recursive: true }, (evt, name) => {
  console.log('%s changed.', name);
});

gaze, watch, filewatcher 属于早期生态。它们大多基于轮询(polling)或早期的 fs.watch 封装,缺乏对现代文件系统特性的支持。

// gaze: 旧式 API (已归档)
const gaze = require('gaze');
gaze('src/**/*', function(err, files) {
  this.on('changed', function(file) {
    console.log(file + ' was changed');
  });
});

⚡ 性能与大规模文件处理

当监听包含数千文件的目录(如 node_modules)时,性能差异变得明显。

chokidar 性能优异,但在极端情况下(如监听整个磁盘根目录)仍可能消耗较多资源。它允许你通过 ignored 选项排除目录来优化。

// chokidar: 优化大规模监听
const watcher = chokidar.watch('.', {
  ignored: (path) => path.includes('node_modules') || path.includes('.git')
});

watchpack 在这方面表现最佳。它默认不监听 node_modules 中的每个文件,而是监听目录的时间戳。只有当目录时间戳变化时,它才会深入检查。这极大地减少了文件描述符的占用。

// watchpack: 目录级监听优化
const wp = new Watchpack();
// 它智能地决定监听文件还是目录,以节省资源
wp.watch(['index.js'], ['src', 'node_modules']);

node-watch 在文件数量巨大时,由于纯 JS 实现和可能的轮询回退,CPU 占用可能高于 chokidar。它适合中小型项目或对原生模块有限制的场景。

// node-watch: 限制递归深度
watch('src', { recursive: true, maxDepth: 3 }, (evt, name) => {
  // 处理逻辑
});

gazewatch 在大规模文件树下表现较差,容易发生事件丢失或内存泄漏,这也是它们被现代工具弃用的主要原因。

// watch: 缺乏现代优化
const watch = require('watch');
watch.watchTree('src', function (f, curr, prev) {
  // 在大量文件变更时可能阻塞事件循环
});

🛡️ 稳定性与边缘情况处理

文件系统操作充满不确定性:编辑器如何保存文件?是原子写入还是直接覆盖?网络驱动器是否支持事件?

chokidar 处理得最完善。它能区分 add, change, unlink, unlinkDir 等细粒度事件,并能处理文件重命名(通常表现为 unlink + add)。

// chokidar: 细粒度事件
watcher
  .on('add', path => console.log(`File ${path} was added`))
  .on('unlink', path => console.log(`File ${path} was removed`))
  .on('error', error => console.log(`Watcher error: ${error}`));

watchpack 抽象了这些细节,它更关心“构建是否需要重新运行”。它提供 aggregated 事件,将短时间内的多次变更合并为一次通知,防止构建风暴。

// watchpack: 事件聚合
wp.on('aggregated', (changes, removals) => {
  // 一次性处理所有变更,适合触发构建
  rebuild(changes);
});

node-watch 提供了类似 chokidar 的事件,但在某些网络文件系统(NAS)上可能需要强制开启轮询模式才能可靠工作。

// node-watch: 强制轮询模式
watch('src', { recursive: true, usePolling: true }, (evt, name) => {
  // 在 NFS 或 Docker 挂载卷上更可靠
});

sane 曾经试图提供统一的接口(支持 Watchman, fsevents 等),但配置复杂且维护停滞。现在除非你在使用旧版 React Native 或 Jest,否则不应考虑。

// sane: 复杂的后端选择 (已不推荐)
const sane = require('sane');
const watcher = sane('src', { glob: ['**/*.js'] });
watcher.on('change', (filepath, root, stat) => { });

📦 依赖与安装体验

chokidar 在 macOS 上依赖 fsevents,这是一个可选的原生依赖。如果编译失败,它会自动回退到原生 fs.watch,保证安装不会报错,但性能会下降。

node-watch 没有原生依赖,安装速度最快,且在 CI/CD 环境或 Alpine Linux 等精简容器中无需安装 Python 或 C++ 构建工具。

watchpack 同样依赖 fsevents 作为可选依赖,但其核心逻辑对原生模块的依赖较少,更侧重于 JS 层的逻辑优化。

gaze, watch, filewatcher 虽然也没有复杂的原生依赖,但由于不再维护,可能存在未修复的安全漏洞或兼容性 Bug。

📊 总结对比表

特性chokidarwatchpacknode-watchgaze / watch
维护状态✅ 积极维护✅ 积极维护✅ 积极维护❌ 已归档/停止
原生依赖可选 (fsevents)可选 (fsevents)无 (纯 JS)
递归监听✅ 支持✅ 支持 (智能)✅ 支持⚠️ 有限支持
事件聚合❌ (需自行实现)✅ 内置支持
适用场景通用应用/DevServer构建工具/Bundler无原生环境/容器❌ 不推荐
API 复杂度

💡 架构师建议

对于 90% 的前端项目,直接使用 chokidar。它是经过生产环境验证的“安全选择”,文档完善,社区支持好,能帮你避开绝大多数文件监听的坑。

如果你在开发构建工具(如自定义的 Webpack Loader 或 Bundler),请研究 watchpack。它对大量文件监听的优化策略(目录时间戳轮询)是 chokidar 不具备的,能显著提升大型项目的构建性能。

如果你在容器化环境或无构建工具链的环境中node-watch 是一个轻量且可靠的替代品,特别是当你想避免 node-gyp 编译问题时。

对于 gaze, watch, sane, filewatcher,请将它们视为“遗留技术”。如果在新项目中看到它们,建议制定计划迁移到 chokidar,以减少未来的维护负担和潜在风险。

如何选择: chokidar vs filewatcher vs gaze vs node-watch vs sane vs watch vs watchpack

  • chokidar:

    选择 chokidar 作为大多数项目的默认方案。它是目前生态中最成熟、维护最积极的库,被 Vite、Webpack 等主流工具采用。如果你需要跨平台一致性、递归监听和高性能,这是首选。

  • filewatcher:

    不建议在新项目中使用 filewatcher。该库处于非活跃状态,功能较为基础,缺乏对复杂场景(如网络文件系统、大量文件)的优化,社区已转向更现代的替代方案。

  • gaze:

    不建议在新项目中使用 gaze。该库已归档(archived),不再维护。虽然它曾经流行于 Grunt 时代,但现代项目应迁移到 chokidar 以获得更好的支持和安全性。

  • node-watch:

    选择 node-watch 如果你希望避免原生绑定(native bindings)或 C++ 依赖,纯 JavaScript 实现更易于调试和在某些受限环境中运行。它在性能和兼容性之间取得了不错的平衡。

  • sane:

    不建议在新项目中使用 sane。虽然它曾被 Jest 使用,但现已不再积极维护,且社区支持度下降。除非你维护依赖它的旧版工具链,否则应评估迁移到 chokidar

  • watch:

    不建议在新项目中使用 watch。这是一个非常古老的库,功能有限且不再维护。它的 API 设计较旧,缺乏现代文件监听所需的递归和去抖动特性。

  • watchpack:

    选择 watchpack 如果你正在开发类似 Webpack 的构建工具,且需要处理巨大的 node_modules 目录。它针对大规模文件树进行了优化,支持延迟监听和聚合事件,适合构建场景而非通用应用。

chokidar的README

Chokidar Weekly downloads

Minimal and efficient cross-platform file watching library

Why?

There are many reasons to prefer Chokidar to raw fs.watch / fs.watchFile in 2026:

  • Events are properly reported
    • macOS events report filenames
    • events are not reported twice
    • changes are reported as add / change / unlink instead of useless rename
  • Atomic writes are supported, using atomic option
    • Some file editors use them
  • Chunked writes are supported, using awaitWriteFinish option
    • Large files are commonly written in chunks
  • File / dir filtering is supported
  • Symbolic links are supported
  • Recursive watching is always supported, instead of partial when using raw events
    • Includes a way to limit recursion depth

Chokidar relies on the Node.js core fs module, but when using fs.watch and fs.watchFile for watching, it normalizes the events it receives, often checking for truth by getting file stats and/or dir contents. The fs.watch-based implementation is the default, which avoids polling and keeps CPU usage down. Be advised that chokidar will initiate watchers recursively for everything within scope of the paths that have been specified, so be judicious about not wasting system resources by watching much more than needed. For some cases, fs.watchFile, which utilizes polling and uses more resources, is used.

Made for Brunch in 2012, it is now used in ~30 million repositories and has proven itself in production environments.

  • Nov 2025 update: v5 is out. Makes package ESM-only and increases minimum node.js requirement to v20.
  • Sep 2024 update: v4 is out! It decreases dependency count from 13 to 1, removes support for globs, adds support for ESM / Common.js modules, and bumps minimum node.js version from v8 to v14. Check out upgrading.

Getting started

Install with npm:

npm install chokidar

Use it in your code:

import chokidar from 'chokidar';

// One-liner for current directory
chokidar.watch('.').on('all', (event, path) => {
  console.log(event, path);
});

// Extended options
// ----------------

// Initialize watcher.
const watcher = chokidar.watch('file, dir, or array', {
  ignored: (path, stats) => stats?.isFile() && !path.endsWith('.js'), // only watch js files
  persistent: true,
});

// Something to use when events are received.
const log = console.log.bind(console);
// Add event listeners.
watcher
  .on('add', (path) => log(`File ${path} has been added`))
  .on('change', (path) => log(`File ${path} has been changed`))
  .on('unlink', (path) => log(`File ${path} has been removed`));

// More possible events.
watcher
  .on('addDir', (path) => log(`Directory ${path} has been added`))
  .on('unlinkDir', (path) => log(`Directory ${path} has been removed`))
  .on('error', (error) => log(`Watcher error: ${error}`))
  .on('ready', () => log('Initial scan complete. Ready for changes'))
  .on('raw', (event, path, details) => {
    // internal
    log('Raw event info:', event, path, details);
  });

// 'add', 'addDir' and 'change' events also receive stat() results as second
// argument when available: https://nodejs.org/api/fs.html#fs_class_fs_stats
watcher.on('change', (path, stats) => {
  if (stats) console.log(`File ${path} changed size to ${stats.size}`);
});

// Watch new files.
watcher.add('new-file');
watcher.add(['new-file-2', 'new-file-3']);

// Get list of actual paths being watched on the filesystem
let watchedPaths = watcher.getWatched();

// Un-watch some files.
await watcher.unwatch('new-file');

// Stop watching. The method is async!
await watcher.close().then(() => console.log('closed'));

// Full list of options. See below for descriptions.
// Do not use this example!
chokidar.watch('file', {
  persistent: true,

  // ignore .txt files
  ignored: (file) => file.endsWith('.txt'),
  // watch only .txt files
  // ignored: (file, _stats) => _stats?.isFile() && !file.endsWith('.txt'),

  awaitWriteFinish: true, // emit single event when chunked writes are completed
  atomic: true, // emit proper events when "atomic writes" (mv _tmp file) are used

  // The options also allow specifying custom intervals in ms
  // awaitWriteFinish: {
  //   stabilityThreshold: 2000,
  //   pollInterval: 100
  // },
  // atomic: 100,

  interval: 100,
  binaryInterval: 300,

  cwd: '.',
  depth: 99,

  followSymlinks: true,
  ignoreInitial: false,
  ignorePermissionErrors: false,
  usePolling: false,
  alwaysStat: false,
});

chokidar.watch(paths, [options])

  • paths (string or array of strings). Paths to files, dirs to be watched recursively.
  • options (object) Options object as defined below:

Persistence

  • persistent (default: true). Indicates whether the process should continue to run as long as files are being watched.

Path filtering

  • ignored function, regex, or path. Defines files/paths to be ignored. The whole relative or absolute path is tested, not just filename. If a function with two arguments is provided, it gets called twice per path - once with a single argument (the path), second time with two arguments (the path and the fs.Stats object of that path).
  • ignoreInitial (default: false). If set to false then add/addDir events are also emitted for matching paths while instantiating the watching as chokidar discovers these file paths (before the ready event).
  • followSymlinks (default: true). When false, only the symlinks themselves will be watched for changes instead of following the link references and bubbling events through the link's path.
  • cwd (no default). The base directory from which watch paths are to be derived. Paths emitted with events will be relative to this.

Performance

  • usePolling (default: false). Whether to use fs.watchFile (backed by polling), or fs.watch. If polling leads to high CPU utilization, consider setting this to false. It is typically necessary to set this to true to successfully watch files over a network, and it may be necessary to successfully watch files in other non-standard situations. Setting to true explicitly on MacOS overrides the useFsEvents default. You may also set the CHOKIDAR_USEPOLLING env variable to true (1) or false (0) in order to override this option.
  • Polling-specific settings (effective when usePolling: true)
    • interval (default: 100). Interval of file system polling, in milliseconds. You may also set the CHOKIDAR_INTERVAL env variable to override this option.
    • binaryInterval (default: 300). Interval of file system polling for binary files. (see list of binary extensions)
  • alwaysStat (default: false). If relying upon the fs.Stats object that may get passed with add, addDir, and change events, set this to true to ensure it is provided even in cases where it wasn't already available from the underlying watch events.
  • depth (default: undefined). If set, limits how many levels of subdirectories will be traversed.
  • awaitWriteFinish (default: false). By default, the add event will fire when a file first appears on disk, before the entire file has been written. Furthermore, in some cases some change events will be emitted while the file is being written. In some cases, especially when watching for large files there will be a need to wait for the write operation to finish before responding to a file creation or modification. Setting awaitWriteFinish to true (or a truthy value) will poll file size, holding its add and change events until the size does not change for a configurable amount of time. The appropriate duration setting is heavily dependent on the OS and hardware. For accurate detection this parameter should be relatively high, making file watching much less responsive. Use with caution.
    • options.awaitWriteFinish can be set to an object in order to adjust timing params:
    • awaitWriteFinish.stabilityThreshold (default: 2000). Amount of time in milliseconds for a file size to remain constant before emitting its event.
    • awaitWriteFinish.pollInterval (default: 100). File size polling interval, in milliseconds.

Errors

  • ignorePermissionErrors (default: false). Indicates whether to watch files that don't have read permissions if possible. If watching fails due to EPERM or EACCES with this set to true, the errors will be suppressed silently.
  • atomic (default: true if useFsEvents and usePolling are false). Automatically filters out artifacts that occur when using editors that use "atomic writes" instead of writing directly to the source file. If a file is re-added within 100 ms of being deleted, Chokidar emits a change event rather than unlink then add. If the default of 100 ms does not work well for you, you can override it by setting atomic to a custom value, in milliseconds.

Methods & Events

chokidar.watch() produces an instance of FSWatcher. Methods of FSWatcher:

  • .add(path / paths): Add files, directories for tracking. Takes an array of strings or just one string.
  • .on(event, callback): Listen for an FS event. Available events: add, addDir, change, unlink, unlinkDir, ready, raw, error. Additionally all is available which gets emitted with the underlying event name and path for every event other than ready, raw, and error. raw is internal, use it carefully.
  • .unwatch(path / paths): Stop watching files or directories. Takes an array of strings or just one string.
  • .close(): async Removes all listeners from watched files. Asynchronous, returns Promise. Use with await to ensure bugs don't happen.
  • .getWatched(): Returns an object representing all the paths on the file system being watched by this FSWatcher instance. The object's keys are all the directories (using absolute paths unless the cwd option was used), and the values are arrays of the names of the items contained in each directory.

CLI

Check out third party chokidar-cli, which allows to execute a command on each change, or get a stdio stream of change events.

Troubleshooting

Sometimes, Chokidar runs out of file handles, causing EMFILE and ENOSP errors:

  • bash: cannot set terminal process group (-1): Inappropriate ioctl for device bash: no job control in this shell
  • Error: watch /home/ ENOSPC

There are two things that can cause it.

  1. Exhausted file handles for generic fs operations
    • Can be solved by using graceful-fs, which can monkey-patch native fs module used by chokidar: let fs = require('fs'); let grfs = require('graceful-fs'); grfs.gracefulify(fs);
    • Can also be solved by tuning OS: echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p.
  2. Exhausted file handles for fs.watch
    • Can't seem to be solved by graceful-fs or OS tuning
    • It's possible to start using usePolling: true, which will switch backend to resource-intensive fs.watchFile

All fsevents-related issues (WARN optional dep failed, fsevents is not a constructor) are solved by upgrading to v4+.

Changelog

  • v4 (Sep 2024): remove glob support and bundled fsevents. Decrease dependency count from 13 to 1. Rewrite in typescript. Bumps minimum node.js requirement to v14+
  • v3 (Apr 2019): massive CPU & RAM consumption improvements; reduces deps / package size by a factor of 17x and bumps Node.js requirement to v8.16+.
  • v2 (Dec 2017): globs are now posix-style-only. Tons of bugfixes.
  • v1 (Apr 2015): glob support, symlink support, tons of bugfixes. Node 0.8+ is supported
  • v0.1 (Apr 2012): Initial release, extracted from Brunch

Upgrading

If you've used globs before and want do replicate the functionality with v4:

// v3
chok.watch('**/*.js');
chok.watch('./directory/**/*');

// v4
chok.watch('.', {
  ignored: (path, stats) => stats?.isFile() && !path.endsWith('.js'), // only watch js files
});
chok.watch('./directory');

// other way
import { glob } from 'node:fs/promises';
const watcher = watch(await Array.fromAsync(glob('**/*.js')));

// unwatching
// v3
chok.unwatch('**/*.js');
// v4
chok.unwatch(await Array.fromAsync(glob('**/*.js')));

Also

Why was chokidar named this way? What's the meaning behind it?

Chowkidar is a transliteration of a Hindi word meaning 'watchman, gatekeeper', चौकीदार. This ultimately comes from Sanskrit _ चतुष्क_ (crossway, quadrangle, consisting-of-four). This word is also used in other languages like Urdu as (چوکیدار) which is widely used in Pakistan and India.

License

MIT (c) Paul Miller (https://paulmillr.com), see LICENSE file.