Weave Code
Laravel filesystem watcher
Frequently asked questions about Laravel Inotify
- What does octopyid/laravel-inotify actually do?
- It is a thin Laravel wrapper around Linux inotify that watches filesystem changes and emits events, exposed through a service provider, a facade, and an artisan-facing watcher. Typical uses sit in the developer-experience and operational automation layer: clearing view or config caches, restarting queue workers on deploy, triggering asset builds, or reacting to uploaded-file drops. It is not an event-bus replacement and does not belong in a request-serving code path.
- What are the requirements for installing octopyid/laravel-inotify?
- It is Composer-installable with package auto-discovery and MIT-licensed, but it requires either the ext-inotify PHP extension or the inotify-tools binary, which makes it Linux-only. Confirm the extension is compiled into your base image with php -m | grep inotify. You should also raise fs.inotify.max_user_watches in the runtime environment before relying on it.
- Does laravel-inotify work on macOS, Windows, WSL, or inside Docker?
- Not on macOS or Windows natively, and WSL-mounted paths, NFS, and many overlay or container filesystems either fail outright or deliver unreliable events. The supported combination is native Linux or a Linux container running on a Linux host, ideally with host-mounted source in development. Start any integration plan with a base-image capability check rather than a code review.
- Which Laravel and PHP versions does octopyid/laravel-inotify support?
- Its constraint set dates from 2022 and targets Laravel 8/9-era applications on PHP 7.4 through 8.1. Because the repository is archived, there has been no Laravel 10 or 11 compatibility work. Expect to widen or override the composer constraints, and to patch service provider signatures, facade registration, and PHP 8.2+ dynamic-property deprecations yourself.
- Is octopyid/laravel-inotify still maintained?
- No. The repository is archived, the last release was 2022-06-28, it has roughly 13 stars, and it is effectively a single-maintainer project. That means no security patching, no upstream bug triage, and no framework compatibility fixes. Budget for it as an internal fork you own rather than assuming an MIT dependency is free.
- Can I safely use laravel-inotify in production?
- Technical risk is high for anything beyond local tooling. Watch out for blocking I/O inside a PHP process, recursive-watch memory growth, max_user_watches and max_user_instances exhaustion, and silent watcher death that produces no alert. If you have a real production trigger requirement, a queue or object-store event source is a more reliable foundation than filesystem watching.
- How do I restart queue workers or clear caches when files change in Laravel?
- That is the intended use case: the watcher emits events on create, modify, delete, and move, and you react by dispatching artisan commands such as queue restarts or cache clears. Wrap the package behind an internal FileWatcher contract so no domain code depends on it directly. Timebox a spike in a disposable Linux dev container to confirm events actually fire in your environment.
- What are the alternatives to octopyid/laravel-inotify?
- For asset watching, Vite or chokidar are maintained and cross-platform. For runtime triggers, a queue or object-store event source beats filesystem polling on reliability. For local developer experience, shelling out to inotifywait directly is reasonable, since the package surface is thin enough that re-implementing it is cheaper than maintaining an abandoned wrapper.
- How do I test laravel-inotify in CI?
- CI must run on a Linux runner because the tests will not be portable to macOS or Windows images. The base image needs ext-inotify or inotify-tools available, plus raised inotify watch limits for recursive watches. Add an explicit capability check step before running the suite so environment failures are obvious rather than appearing as flaky tests.
- Should I fork octopyid/laravel-inotify or use it as a Composer dependency?
- For anything you intend to keep, treat it as vendored code rather than a dependency. Fork it into an internal namespace, pin to the archived commit for provenance, and apply compatibility shims as Laravel and PHP versions move forward. If the requirement grows beyond local developer experience, the fallback is to shell out to inotifywait and drop the wrapper entirely.
Weaver
How can I help you explore Laravel packages today?