Fswatch Laravel Package

Product Decisions This Supports

• Feature scoping: Useful only for low-stakes change detection where a coarse “directory size changed” signal is enough, such as invalidating a local cache, triggering a simple asset rebuild, or checking whether a fixture/import directory may have changed.
• Build vs. buy: Strongly favors build in-house. The package’s core behavior—summing file sizes in a directory—is small enough to implement directly with Laravel/PHP filesystem APIs, while avoiding an unproven dependency and unclear licensing.
• Roadmap priority: Not a strategic dependency. It should not enter the roadmap as infrastructure for core product behavior, customer-facing freshness guarantees, or production-critical cache invalidation.
• Use-case fit: Appropriate for internal tooling, prototypes, local developer workflows, and non-critical “maybe changed” checks. Inappropriate where missed changes, false positives, or auditability matter.
• Risk decision: With 1 star, 0 dependents, a NOASSERTION license, and a size-only heuristic, adoption should be treated as a tactical convenience only after legal and engineering review—not as a platform standard.

When to Consider This Package

Consider it only when all or most of these are true:

• You need a very cheap, coarse signal that files in a single directory may have changed.
• False positives and false negatives are acceptable because the check is a hint, not a source of truth.
• The directory is small, locally mounted, and not subject to concurrent writes during measurement.
• You are already in a Slick/PHP context, or the dependency cost is negligible for an internal script.
• You can tolerate a size-sum heuristic: same-size edits can be missed, and different file combinations can produce the same total size.
• Legal has reviewed the NOASSERTION license and approved use.
• You are not relying on it for security, compliance, billing, data integrity, or production cache correctness.

Look elsewhere or build in-house when:

• You need reliable file watching, recursive traversal, include/exclude rules, debouncing, or cross-platform event handling.
• You need content-aware detection via hashes, mtimes, inodes, or manifests rather than total byte size.
• The directory is large, remote, distributed, or changing during the scan.
• The package would sit in a critical path where missed invalidation causes stale data, broken builds, or user-visible defects.
• You require clear licensing, active maintenance, broad adoption, or long-term support.
• A framework-native solution is preferable: Laravel’s filesystem APIs plus a custom hash/manifest, Symfony Finder with hashing, or platform file-watching tools.

How to Pitch It (Stakeholders)

For executives: This is a tiny utility, not a strategic platform component. It can help with low-risk internal change detection, but its adoption profile—1 star, 0 dependents, unclear license, and a size-only heuristic—makes it unsuitable for customer-facing or business-critical freshness guarantees. The recommended position is “do not standardize; build a small internal equivalent if the need is real.”

For engineering: The package sums file sizes in a directory to infer whether contents changed. That is inexpensive but weak: it can miss same-size edits and can produce collisions. If we need this capability, implement a small, explicit utility using Laravel/PHP filesystem APIs with defined semantics—directory scope, recursion, exclusions, and a hash or manifest where correctness matters. Avoid adding a low-adoption dependency for behavior we can own in a few dozen lines.