Safeguard
Open Source

chokidar on npm: A Security Review of the File-Watching Library

chokidar is the file-watching library behind most of the Node.js tooling ecosystem, and version 4 cut its dependency count from 13 to 1. Here is what that means for your supply chain risk.

Yukti Singhal
Security Analyst
6 min read

chokidar is the cross-platform file-watching library that sits under a huge portion of the Node.js tooling ecosystem, and its version 4 release is a genuine supply chain win because it cut the dependency count from 13 to just 1 and dropped the bundled fsevents native module. If you run a build tool, a dev server, a test watcher, or a linter in watch mode, you are almost certainly depending on chokidar transitively, which makes its dependency footprint everyone's problem.

This review explains what chokidar does, why the v4 slimming matters for security, and how to keep it healthy in your tree.

What chokidar does

chokidar turns low-level filesystem notifications into clean, normalized add, change, and unlink events. It wraps Node's core fs.watch and fs.watchFile and smooths over the platform inconsistencies that make raw filesystem watching painful — duplicate events, missing events, and different behavior across macOS, Linux, and Windows. It handles recursive watching, symlinks, and atomic or chunked writes, and it prefers the event-based fs.watch over polling to keep CPU usage low.

Because it solves a genuinely annoying cross-platform problem well, it became the default watcher for a long list of popular tools. That ubiquity is exactly why its dependency hygiene matters: a problem in chokidar propagates to an enormous fan of downstream packages.

Why version 4 is a security improvement

chokidar 4.0.0, released in September 2024, is a substantial rewrite, and several of its changes reduce supply chain risk directly.

The headline is the dependency reduction from 13 packages to 1. Every transitive dependency is a package you have to trust, keep patched, and worry about being compromised or abandoned. Cutting twelve of them out of the tree removes twelve independent sources of risk from every project that depends on chokidar. For a package this widely used, that is a meaningful reduction in the aggregate ecosystem attack surface.

Version 4 also removed built-in glob support. In earlier versions, chokidar bundled glob-matching dependencies so you could watch patterns directly. Those glob libraries were part of the transitive weight and, historically, a recurring source of regular-expression and matching-related advisories elsewhere in the ecosystem. Moving glob handling out and expecting callers to resolve paths themselves is a cleaner boundary.

The rewrite to TypeScript and the shift to a hybrid CommonJS/ESM package come with a higher minimum Node.js version, which is worth planning for but is also part of a healthier posture: dropping support for very old runtimes lets maintainers avoid shims and compatibility code that tend to hide bugs.

The fsevents change and what it means

Earlier chokidar bundled fsevents, an optional native module that provides efficient file watching on macOS. Version 4 removes it from the bundle. This has two effects worth understanding.

On the risk side, native modules ship compiled binaries and are a category worth scrutinizing, so having one fewer optional-native dependency baked in is a reduction in complexity. On the behavior side, chokidar 4 relies on Node's core fs.watch across platforms rather than a macOS-specific native path. For the vast majority of applications this is transparent, but if you specifically depended on fsevents-backed behavior on macOS, validate that the core watcher meets your needs before upgrading.

Keeping chokidar safe in your stack

Because chokidar is almost always a transitive dependency, the practical work is about your tree, not the package itself.

Check which version resolves in your project:

npm ls chokidar

If you see multiple copies at different major versions — common when different tools pin different ranges — you are carrying the older, heavier dependency tree through whichever tool pinned it. Where you can, update those tools to versions that depend on chokidar 4 so the whole tree collapses onto the slimmer graph. Deduplication here is a real reduction in surface area, not just a tidiness exercise.

Keep the package current for the ordinary reason: even a well-maintained library ships fixes, and staying within a supported major line means you receive them. An SCA scanner will flag if any resolved copy of chokidar — or something in its remaining dependency — picks up a published advisory, across all your services at once rather than one npm ls at a time.

Is chokidar well maintained?

Yes. chokidar is actively maintained by a well-known author in the Node.js ecosystem, and the v4 rewrite is exactly the kind of deliberate slimming you want to see from a foundational library: fewer dependencies, a modern codebase, and a cleaner API boundary. There is no reason to avoid it, and a v4-based tree is a better place to be than the older, dependency-heavy line. If you want a framework for judging dependency health more generally, our OpenSSF Scorecard guide covers the signals that matter.

FAQ

Is the chokidar npm package safe to use?

Yes. chokidar is a widely used, actively maintained file-watching library, and version 4 improved its security posture by cutting its dependency count from 13 to 1 and modernizing the codebase. Keep it on a supported major line and it is a safe, foundational dependency.

What changed in chokidar version 4?

Version 4 (September 2024) is a rewrite that reduced dependencies from 13 to 1, removed bundled glob support, dropped the bundled fsevents native module, converted the code to TypeScript, and shipped as a hybrid CommonJS/ESM package with a higher minimum Node.js version.

Why does chokidar's dependency count matter for security?

Every transitive dependency is a package you must trust and keep patched, and any one of them can be compromised or abandoned. Because chokidar sits under so much tooling, shrinking its tree from 13 packages to 1 removes many independent risk sources across the entire ecosystem that depends on it.

How do I know which version of chokidar I have?

Run npm ls chokidar to see every resolved copy in your dependency tree. Multiple copies at different majors mean some tools still pin the older, heavier version. Updating those tools to ones that use chokidar 4 lets the tree deduplicate onto the slimmer graph.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.