watchpack vs chokidar vs gaze vs node-watch vs sane
文件监视库
watchpackchokidargazenode-watchsane类似的npm包:

文件监视库

文件监视库用于监控文件系统中的变化,例如文件的创建、修改和删除。这些库通常用于开发工具中,以便在文件变化时自动执行某些操作,如重新编译代码或重新加载页面。它们提供了高效的方式来监听文件变化,帮助开发者提高工作效率。

npm下载趋势

3 年

GitHub Stars 排名

统计详情

npm包名称
下载量
Stars
大小
Issues
发布时间
License
watchpack46,305,063400108 kB132 个月前MIT
chokidar012,22082.1 kB449 个月前MIT
gaze01,150-688 年前MIT
node-watch034226.1 kB83 年前MIT
sane0387-345 年前MIT

功能对比: watchpack vs chokidar vs gaze vs node-watch vs sane

性能

  • watchpack:

    Watchpack专为Webpack设计,能够高效处理模块的变化,性能优化良好,适合大型项目。

  • chokidar:

    Chokidar使用高效的文件系统API,能够快速响应文件变化,支持大量文件的监视而不会显著影响性能。

  • gaze:

    Gaze的性能适中,适合小型项目,但在处理大量文件时可能会出现性能瓶颈。

  • node-watch:

    Node-watch的性能相对较好,适合基本的监视需求,但在复杂场景下可能不够高效。

  • sane:

    Sane在处理大量文件变化时表现出色,能够有效减少CPU和内存的使用,适合高性能需求。

平台支持

  • watchpack:

    Watchpack主要用于Webpack环境,适合与Webpack的集成,支持多平台。

  • chokidar:

    Chokidar支持多种操作系统,包括Linux、macOS和Windows,具有良好的跨平台兼容性。

  • gaze:

    Gaze同样支持主要操作系统,但在某些平台上的表现可能不如Chokidar。

  • node-watch:

    Node-watch支持跨平台使用,适合大多数Node.js环境。

  • sane:

    Sane支持多种平台,能够在不同操作系统上稳定运行。

API设计

  • watchpack:

    Watchpack的API专为Webpack设计,提供了与Webpack构建流程紧密集成的功能。

  • chokidar:

    Chokidar提供了丰富且灵活的API,允许开发者自定义监视行为,支持多种事件类型。

  • gaze:

    Gaze的API设计简单直观,易于使用,适合快速开发。

  • node-watch:

    Node-watch的API相对简单,适合基本的监视需求,但功能较为有限。

  • sane:

    Sane的API设计合理,支持多种配置选项,适合复杂的监视需求。

使用场景

  • watchpack:

    Watchpack适合Webpack项目,能够高效监视模块变化并触发构建。

  • chokidar:

    Chokidar适合需要实时监视大量文件变化的场景,如构建工具、自动化任务等。

  • gaze:

    Gaze适合小型项目或简单的文件监视任务,如自动重载开发服务器。

  • node-watch:

    Node-watch适合轻量级的文件监视需求,适合快速开发和原型设计。

  • sane:

    Sane适合需要高效监视的场景,如大型项目的构建过程。

社区支持

  • watchpack:

    Watchpack作为Webpack的一部分,享有Webpack社区的支持,文档和资源丰富。

  • chokidar:

    Chokidar拥有活跃的社区和良好的文档支持,易于获取帮助和资源。

  • gaze:

    Gaze的社区相对较小,但文档清晰,适合简单使用。

  • node-watch:

    Node-watch的社区支持一般,适合基本需求,但可能缺乏深入的资源。

  • sane:

    Sane的社区支持良好,文档详细,适合复杂使用场景。

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

  • watchpack:

    选择Watchpack如果你需要一个专门为Webpack设计的文件监视解决方案。它能够与Webpack无缝集成,适合构建大型应用程序时使用。

  • chokidar:

    选择Chokidar如果你需要一个功能强大且高效的文件监视库,支持多种操作系统,并且能够处理大量文件的变化。它提供了丰富的API,适合复杂的监视需求。

  • gaze:

    选择Gaze如果你需要一个简单易用的文件监视库,适合小型项目或简单的文件监视任务。它的API设计直观,易于上手,适合快速开发。

  • node-watch:

    选择Node-watch如果你需要一个轻量级的监视库,能够快速集成到现有项目中。它的功能相对简单,适合基本的文件监视需求。

  • sane:

    选择Sane如果你需要一个高效且可靠的文件监视库,能够处理大量文件变化并且支持多种平台。它的性能表现优异,适合需要高效监视的场景。

watchpack的README

watchpack

Wrapper library for directory and file watching.

Test Codecov Downloads

Concept

watchpack high level API doesn't map directly to watchers. Instead a three level architecture ensures that for each directory only a single watcher exists.

  • The high level API requests DirectoryWatchers from a WatcherManager, which ensures that only a single DirectoryWatcher per directory is created.
  • A user-faced Watcher can be obtained from a DirectoryWatcher and provides a filtered view on the DirectoryWatcher.
  • Reference-counting is used on the DirectoryWatcher and Watcher to decide when to close them.
  • The real watchers are created by the DirectoryWatcher.
  • Files are never watched directly. This should keep the watcher count low.
  • Watching can be started in the past. This way watching can start after file reading.
  • Symlinks are not followed, instead the symlink is watched.

API

const Watchpack = require("watchpack");

const wp = new Watchpack({
	// options:
	aggregateTimeout: 1000,
	// fire "aggregated" event when after a change for 1000ms no additional change occurred
	// aggregated defaults to undefined, which doesn't fire an "aggregated" event

	poll: true,
	// poll: true - use polling with the default interval
	// poll: 10000 - use polling with an interval of 10s
	// poll defaults to undefined, which prefer native watching methods
	// Note: enable polling when watching on a network path
	// When WATCHPACK_POLLING environment variable is set it will override this option

	followSymlinks: true,
	// true: follows symlinks and watches symlinks and real files
	//   (This makes sense when symlinks has not been resolved yet, comes with a performance hit)
	// false (default): watches only specified item they may be real files or symlinks
	//   (This makes sense when symlinks has already been resolved)

	ignored: "**/.git",
	// ignored: "string" - a glob pattern for files or folders that should not be watched
	// ignored: ["string", "string"] - multiple glob patterns that should be ignored
	// ignored: /regexp/ - a regular expression for files or folders that should not be watched
	// ignored: (entry) => boolean - an arbitrary function which must return truthy to ignore an entry
	// For all cases expect the arbitrary function the path will have path separator normalized to '/'.
	// All subdirectories are ignored too
});

// Watchpack.prototype.watch({
//   files: Iterable<string>,
//   directories: Iterable<string>,
//   missing: Iterable<string>,
//   startTime?: number
// })
wp.watch({
	files: listOfFiles,
	directories: listOfDirectories,
	missing: listOfNotExistingItems,
	startTime: Date.now() - 10000,
});
// starts watching these files and directories
// calling this again will override the files and directories
// files: can be files or directories, for files: content and existence changes are tracked
//        for directories: only existence and timestamp changes are tracked
// directories: only directories, directory content (and content of children, ...) and
//              existence changes are tracked.
//              assumed to exist, when directory is not found without further information a remove event is emitted
// missing: can be files or directories,
//          only existence changes are tracked
//          expected to not exist, no remove event is emitted when not found initially
// files and directories are assumed to exist, when they are not found without further information a remove event is emitted
// missing is assumed to not exist and no remove event is emitted

wp.on("change", (filePath, mtime, explanation) => {
	// filePath: the changed file
	// mtime: last modified time for the changed file
	// explanation: textual information how this change was detected
});

wp.on("remove", (filePath, explanation) => {
	// filePath: the removed file or directory
	// explanation: textual information how this change was detected
});

wp.on("aggregated", (changes, removals) => {
	// changes: a Set of all changed files
	// removals: a Set of all removed files
	// watchpack gives up ownership on these Sets.
});

// Watchpack.prototype.pause()
wp.pause();
// stops emitting events, but keeps watchers open
// next "watch" call can reuse the watchers
// The watcher will keep aggregating events
// which can be received with getAggregated()

// Watchpack.prototype.close()
wp.close();
// stops emitting events and closes all watchers

// Watchpack.prototype.getAggregated(): { changes: Set<string>, removals: Set<string> }
const { changes, removals } = wp.getAggregated();
// returns the current aggregated info and removes that from the watcher
// The next aggregated event won't include that info and will only emitted
// when futher changes happen
// Can also be used when paused.

// Watchpack.prototype.collectTimeInfoEntries(fileInfoEntries: Map<string, Entry>, directoryInfoEntries: Map<string, Entry>)
wp.collectTimeInfoEntries(fileInfoEntries, directoryInfoEntries);
// collects time info objects for all known files and directories
// this include info from files not directly watched
// key: absolute path, value: object with { safeTime, timestamp }
// safeTime: a point in time at which it is safe to say all changes happened before that
// timestamp: only for files, the mtime timestamp of the file

// Watchpack.prototype.getTimeInfoEntries()
const fileTimes = wp.getTimeInfoEntries();
// returns a Map with all known time info objects for files and directories
// similar to collectTimeInfoEntries but returns a single map with all entries

// (deprecated)
// Watchpack.prototype.getTimes()
const fileTimesOld = wp.getTimes();
// returns an object with all known change times for files
// this include timestamps from files not directly watched
// key: absolute path, value: timestamp as number

Environment variables

  • WATCHPACK_POLLING: when set, overrides the poll option (see above).
  • WATCHPACK_RETRIES: number of times to retry fs.lstat when it returns EBUSY (default: 3). Useful on Windows where anti-virus scanners, indexers or editors briefly lock files — without retries watchpack would see a spurious remove and stop tracking the file. Set to 0 or "false" to disable retrying.