Chkokidar; caretaker; systemd.path

We’ve covered filesystem watchers before, and I’m still feeling a tad under the weather, so I’ve stitched together some notes from ones left on the cutting room floor, and tossed in some a shameless promotion for systemd’s built-in watcher feature.

TL;DR

(This is an AI-generated summary of today’s Drop using Ollama + llama 3.2 and a custom prompt.)

• Chokidar 4.0 brings major architectural changes including reduction from 13 to 1 dependency, TypeScript rewrite, and removal of glob support in favor of RegExp filters — https://www.npmjs.com/package/chokidar-cli
• Caretaker provides filesystem monitoring through TOML configuration files, supporting recursive watching and glob patterns while executing shell commands on detected changes — https://github.com/grego/caretaker
• Systemd path units offer built-in filesystem monitoring capabilities to trigger systemd services when specific file events occur, providing a native solution for file-based automation — https://www.redhat.com/en/blog/introduction-path-units

Chkokidar

Chkokidar (GH) 4.0 was released in September 2024, and is a pretty hefty upgrade to this fairly popular Node.js file system watcher. This major version brings architectural changes and modernization to the codebase.

The most notable change is the massive reduction in dependencies, going from 13 to just a single dependency. This streamlining effort includes the removal of the bundled fsevents module, making the package more lightweight and maintainable. The codebase has been completely rewritten in TypeScript, providing enhanced Potemkin-type safety, but does make IDE autocomplete more thorough.

This new version requires Node.js v14 or higher, which enables Chokidar to take advantage of improved cross-platform file system APIs and better performance characteristics.

Chokidar 4.0 introduces hybrid package support, accommodating both CommonJS and ESM environments, making it more versatile across different Node.js application architectures while maintaining backward compatibility wherever possible.

The file watching interface has been refined with the removal of direct glob pattern support. Instead, we can now use more precise file filtering through RegExp and custom functions:

const watcher = chokidar.watch('src', {
  ignored: (path, stats) => {
    return stats?.isFile() && !path.endsWith('.ts')
  }
});

The architectural changes in version 4.0 yield significant performance benefits through:

• Simplified internal logic that reduces overhead
• Direct utilization of platform-specific file system APIs
• Reduced dependency chain improving startup time and memory usage

These improvements make Chokidar 4.0 a more efficient and reliable choice for applications requiring file system monitoring capabilities.

Oh, and if you’re wondering where the name came from… https://en.wikipedia.org/wiki/Chowkidar

caretaker

Caretaker is another filesystem monitoring tool written in Rust that efficiently watches specified paths and executes commands when changes occur. The tool uses a TOML configuration file to define watch rules and commands:

[[watch]]
name = "print hello"
path = "src"
command = "echo $EVENT_PATH"

[[watch]]
name = "compile sass"
path = "sass/*.sass"
command = "sassc -t compressed sass/style.scss static/style.css"

The system monitors specified paths recursively, supporting both directory paths and glob patterns. When a change is detected in any watched path, Caretaker executes the corresponding command.

Commands are executed through the system shell, with several key features:

• Uses $SHELL environment variable by default
• Falls back to sh on Unix systems or cmd.exe on Windows
• Provides the changed file path through $EVENT_PATH environment variable

Caretaker can be installed through two primary methods:

# Using AUR helper
yay -S caretaker-bin

# Using Cargo
cargo install caretaker

To get started with Caretaker:

# Initialize with default config
caretaker init

# Start watching
caretaker

# Use custom config file
caretaker -w custom-config.toml

It leverages the notify crate for efficient event handling across most operating systems, though BSD support is limited. This implementation provides a lightweight and efficient solution for automating responses to filesystem events, making it particularly useful for development workflows and build automation tasks.

systemd.path

Of course I could not let another “watcher” Drop fly by without a nod to the built-in functionality of the nigh ubiquitous systemd.path. It’s a lesser known but super handy feature of systemd unit capability which lets us monitor filesystem paths for changes and then can trigger actions when specific conditions are met. Think of it as a built-in, declarative file watcher that can launch services in response to filesystem events.

Path units are perfect for:

• Monitoring directories for new files
• Watching for file modifications
• Triggering actions when files are deleted
• Responding to file size or timestamp changes

Here’s a practical example that monitors your Downloads directory and automatically organizes files by extension when new ones appear:

# ~/.config/systemd/user/downloads-watcher.path
[Path]
PathExistsGlob=%h/Downloads/*.{pdf,doc,docx,txt}
Unit=downloads-organizer.service

[Install]
WantedBy=default.target

# ~/.config/systemd/user/downloads-organizer.service
[Service]
Type=oneshot
ExecStart=/bin/bash -c 'cd ~/Downloads && for f in *.{pdf,doc,docx,txt}; do [[ -f "$f" ]] && mkdir -p "${f##*.}" && mv "$f" "${f##*.}/"; done'

[Install]
WantedBy=default.target

After creating these files:

systemctl --user enable downloads-watcher.path
systemctl --user start downloads-watcher.path

Now whenever you download documents matching those extensions, they’ll automatically be sorted into type-specific subdirectories.

This is just scratching the surface — path units can be combined with other systemd features like timers and dependencies to create sophisticated file monitoring solutions without external tools.

FIN

Remember, you can follow and interact with the full text of The Daily Drop’s free posts on:

• 🐘 Mastodon via @dailydrop.hrbrmstr.dev@dailydrop.hrbrmstr.dev
• 🦋 Bluesky via https://bsky.app/profile/dailydrop.hrbrmstr.dev.web.brid.gy

Also, refer to:

• this post, and
• this post

to see how to access a regularly updated database of all the Drops with extracted links, and full-text search capability. ☮️