Chokidar
A Node.js library that watches files and folders and reports adds, changes, and deletions reliably.
- Stars
- 12.3k
- Forks
- 639
- Licence
- MIT
- Language
- TypeScript
- Last update
- 10 days ago
- Type
- Library
What it is
Chokidar is a JavaScript/TypeScript library for Node.js that watches files and directories for changes. Raw Node file watching is inconsistent across operating systems, so Chokidar provides normalized add, change, and unlink events, with optional handling for editor saves and large writes. Developers use it inside build tools, dev servers, and scripts that need to react when files change.
- Rerun a build or tests when source files in src change
- Ignore dotfiles and node_modules while watching a project folder
- Wait for large uploads to finish before processing them using awaitWriteFinish
- Watch a network-mounted folder with the polling backend
Great for
- Node.js developers building build tools or dev servers that rerun work on file changes
- Teams that need consistent file events across macOS, Windows, and Linux
- Projects that watch network or unusual filesystems and can accept higher CPU use via polling
- Developers who want to scope watches with ignore rules and depth limits
Not ideal for
- Non-JavaScript projects, since it is a Node.js library (the README does not cover other runtimes)
- People who only need a one-off file check rather than ongoing watching
- Users who want to watch huge trees without filtering, since the README warns it watches everything under the given paths
How to get it
- 1
Install with a package manager
You'll need: Node.js
Install from npm
npm install chokidar - 2
Run it
- Install the package with npm install chokidar
- Import it with import chokidar from 'chokidar' or require it
- Call chokidar.watch('src') and attach an 'all' or 'change' event listener
- Run your script and edit a file in src to see the event printed
- 3
Get the most out of it
- Use ignored with regexes or functions to skip dotfiles and node_modules
- Set ignoreInitial: true to avoid a flood of add events on startup
- Use awaitWriteFinish for large or chunked file writes
- Use atomic to treat editor save-via-rename as a single change
- Use backend: 'polling' for network filesystems where native watching is unreliable
Downloads
Strengths
- Normalizes file events so add, change, and unlink behave more predictably than raw fs.watch
- Uses native file watching by default to keep CPU use low, with polling as a fallback
- Offers filtering, depth limits, and editor atomic-save handling in one API
Trade-offs
- Polling can miss in-place writes that do not change size, modification time, existence, or inode, per the README
- Atomic and write-finish timing involve trade-offs between responsiveness and safety that users must tune
- The README is truncated, so some details of the event API and version changes are not fully visible
How it compares
| Project | Stars | Type | Level | Updated | Best for |
|---|---|---|---|---|---|
| chokidar (this) | 12.3k | Library | intermediate | 10 days ago | Node.js developers building build tools or dev servers that rerun work on file changes |
| nodemon | 26.7k | Dev tool | beginner | 4 days ago | Node.js developers running a web server locally who want fast edit-and-reload cycles |
| watchman | 13.8k | Dev tool | intermediate | 4 days ago | Developers who want to run a build or test when source files change |
| superfile | 24k | App | beginner | 7 days ago | People who spend a lot of time in the terminal and want a visual file browser there |
| flysystem | 13.6k | Library | intermediate | 1 months ago | PHP developers who need to store files in more than one place |
Stats synced from GitHub. The assessment above was drafted with AI from the project's README on 2026-10-29 and may miss recent changes — check the README before relying on a command. MIT licence: free to use, modify and distribute, including commercially, as long as you keep the copyright notice.