这些包用于监测文件系统的变化,常用于开发服务器、构建工具或自动化脚本。chokidar 是目前最稳定且跨平台的库,被广泛集成于主流工具链中。nodemon 是专为开发设计的命令行工具,用于自动重启 Node.js 进程。gaze、sane 和 watch 属于早期方案,现在大多已不再推荐用于新项目,建议优先评估 chokidar。
在 Node.js 生态中,监听文件变化是构建工具、开发服务器和自动化脚本的核心需求。然而,不同操作系统对文件系统事件的实现差异巨大,导致原生 fs.watch 常常不可靠。chokidar、nodemon、node-watch 等包应运而生,旨在解决这些问题。本文将深入对比这些方案的技术细节,帮助你做出正确的架构决策。
启动监听的方式直接影响了代码的可读性和集成难度。
chokidar 提供了链式调用和事件发射器模式,配置灵活。
const chokidar = require('chokidar');
const watcher = chokidar.watch('src/**/*.js', {
ignored: /node_modules/,
persistent: true
});
nodemon 主要作为 CLI 工具使用,但也提供 JS API 用于编程式控制。
const nodemon = require('nodemon');
nodemon({
script: 'app.js',
ext: 'js json',
ignore: ['test/*']
});
node-watch 接口简单,直接返回事件发射器。
const watch = require('node-watch');
const watcher = watch('src', { recursive: true });
gaze 使用构造函数初始化,支持 glob 模式。
const Gaze = require('gaze').Gaze;
const gaze = new Gaze('src/**/*.js');
sane 需要指定具体的后端实现(如 NodeWatcher)。
const watcher = require('sane');
const w = new watcher.NodeWatcher('src');
watch 是最古老的 API 风格,基于回调。
const watch = require('watch');
watch.watchTree('src', function (f, curr, prev) {
// 处理变化
});
处理文件增加、变化和删除的方式决定了业务逻辑的复杂度。
chokidar 区分详细的事件类型,便于精确控制。
watcher
.on('add', path => console.log(`File ${path} added`))
.on('change', path => console.log(`File ${path} changed`))
.on('unlink', path => console.log(`File ${path} removed`));
nodemon 主要关注重启事件,但也允许监听自定义变化。
nodemon.on('restart', files => {
console.log('App restarted due to:', files);
});
node-watch 提供统一的事件流,需判断事件类型。
watcher.on('update', (event, filePath) => {
if (event === 'remove') {
console.log(`${filePath} removed`);
}
});
gaze 通过回调处理特定事件。
gaze.on('all', (event, filepath) => {
console.log(event, filepath);
});
sane 类似 chokidar,使用事件发射器。
w.on('all', (event, filePath) => {
console.log(event, filePath);
});
watch 将所有信息传入单个回调函数。
watch.watchTree('src', function (f, curr, prev) {
if (typeof f == 'object' && f === null) {
// 遍历结束
} else {
console.log('File changed:', f);
}
});
这是选择监听库时最重要的考量因素。Windows、macOS 和 Linux 对文件事件的报告机制完全不同。
chokidar 专为解决跨平台不一致而生。它在 Windows 上使用 fs.watchFile 轮询作为后备,在 Linux 上使用 inotify。它能正确处理文件重命名、原子写入等边缘情况。
// chokidar 自动处理原子写入导致的 unlink/add 序列
watcher.on('unlink', path => {
// 不会因编辑器临时文件误触发
});
node-watch 基于原生 fs.watch,在某些系统上可能会丢失事件或重复触发,适合简单场景。
// 可能在某些系统上对同一变化触发多次
watcher.on('update', (event, filePath) => {
// 需自行去重
});
nodemon 内部通常依赖 chokidar 或其他监听器,专注于进程管理而非底层文件事件稳定性。
// 内部封装了监听逻辑,用户无需关心底层实现
nodemon({ script: 'app.js' });
gaze、sane 和 watch 在旧版系统中表现尚可,但在现代文件系统和高并发写入场景下,容易出现漏报或性能瓶颈。
// 旧库可能无法正确处理大量文件同时变化
gaze.on('all', (event, filepath) => {
// 可能在高负载下丢失事件
});
选择库不仅是选功能,更是选维护团队。废弃的库会带来安全漏洞和兼容性风险。
chokidar 处于活跃维护状态,定期修复 Bug 并适配新 Node.js 版本。它是 Webpack、Vite、Rollup 等主流工具的底层依赖。
nodemon 同样活跃,是 Node.js 开发者的标准配置工具。
node-watch 维护频率较低,但核心功能稳定,适合轻量级需求。
gaze 已停止维护。GitHub 仓库已归档,不再接受 PR 或修复。
sane 主要用于旧版 Jest,现代版本已转向其他方案。通用场景下不再推荐。
watch 极其古老,多年未更新。存在已知问题且无修复计划。
| 特性 | chokidar | nodemon | node-watch | gaze / sane / watch |
|---|---|---|---|---|
| 主要用途 | 构建工具/底层库 | 开发服务器自动重启 | 简单脚本监听 | 遗留系统维护 |
| 跨平台支持 | ✅ 优秀 | ✅ 优秀 (封装) | ⚠️ 一般 | ❌ 较差 |
| API 现代性 | ✅ 现代 Promise/Event | ✅ 配置驱动 | ✅ 简单 | ❌ 古老回调 |
| 维护状态 | 🟢 活跃 | 🟢 活跃 | 🟡 稳定 | 🔴 停止维护 |
| 推荐指数 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ (特定场景) | ⭐⭐⭐ | ❌ 不推荐 |
chokidar 是构建可靠文件监听功能的唯一推荐选择。它 — 就像瑞士军刀一样 — 能处理各种操作系统的怪异行为,让你无需关心底层细节。如果你是在编写打包器、CLI 工具或需要精确控制文件变化的应用,请直接使用它。
nodemon 是开发 Node.js 后端时的最佳伴侣。不要试图用 chokidar 自己写一个重启脚本,除非你有特殊需求。nodemon 已经处理了进程信号、崩溃恢复和配置加载等复杂逻辑。
node-watch 可以作为轻量级替代方案,但请确保你的目标环境单一(例如仅在 Linux 服务器上运行)。
gaze、sane 和 watch 应被视为技术债务。如果你在新项目中看到它们,请计划迁移到 chokidar。它们的存在只会增加未来的维护成本,而不会带来任何现代优势。
核心原则:在基础设施层面,稳定性优于新奇性。文件监听是构建系统的基石,基石不稳,上层建筑随时可能崩塌。选择经过大规模生产环境验证的 chokidar,是对项目长期健康的负责。
选择 chokidar 如果你正在构建需要高可靠性的工具(如打包器、CLI 或自定义开发服务器)。它解决了不同操作系统下文件监听的差异,提供了统一且稳定的 API,是目前社区的事实标准。
不建议在新项目中使用 gaze。该库已停止维护多年,功能已被 chokidar 完全取代。仅在维护遗留代码库时可能遇到,遇到时应计划迁移。
选择 node-watch 如果你需要简单的脚本监听且希望依赖更接近原生 fs.watch 的行为。它比 chokidar 轻量,但在处理复杂跨平台边缘情况时不如 chokidar 稳健。
选择 nodemon 如果你正在开发 Node.js 后端服务,并且需要在文件变化时自动重启进程。它是一个开箱即用的开发工具,而不是用于构建其他工具的底层库。
不建议在新项目中使用 sane。它曾用于 Jest 等工具,但现代工具链已转向 chokidar。除非你是在维护依赖它的旧版测试框架,否则应避免使用。
不建议在新项目中使用 watch。这是一个非常古老的库,缺乏跨平台支持且已不再维护。它的功能有限,无法满足现代开发需求。
Minimal and efficient cross-platform file watching library
There are many reasons to prefer Chokidar to raw fs.watch / fs.watchFile in 2026:
renameatomic option
awaitWriteFinish option
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.
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:persistent (default: true). Indicates whether the process
should continue to run as long as files are being watched.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.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.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.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.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.Check out third party chokidar-cli, which allows to execute a command on each change, or get a stdio stream of change events.
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 shellError: watch /home/ ENOSPCThere are two things that can cause it.
fs module used by chokidar: let fs = require('fs'); let grfs = require('graceful-fs'); grfs.gracefulify(fs);echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p.fs.watch
usePolling: true, which will switch backend to resource-intensive fs.watchFileAll fsevents-related issues (WARN optional dep failed, fsevents is not a constructor) are solved by upgrading to v4+.
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')));
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.
MIT (c) Paul Miller (https://paulmillr.com), see LICENSE file.