Filesystem Adapter Laravel Package

Product Decisions This Supports

• Build vs. buy for caching: buy nothing, build nothing. This is the clearest signal the package sends. Laravel already ships a file cache driver in config/cache.php that requires zero dependencies and zero custom code. Adopting cache/filesystem-adapter means writing a custom Cache\Store wrapper to gain functionality we already have — a net-negative engineering trade. The PM decision this supports is not "let's evaluate a filesystem cache"; it's "we have closed the filesystem-cache question and can redirect that sprint capacity elsewhere."
• PSR-6 interoperability as a scoping question, not a feature request. The one legitimate use case is a polyglot estate: a standalone PHP service, CLI worker, or legacy component that already speaks PSR-6 and needs to share a cache directory with something else. If a roadmap item involves extracting a service out of the monolith into plain PHP (no Laravel container), this package is a plausible 30-minute stopgap. If everything stays inside Laravel, it is not on the table.
• Infrastructure sequencing for early-stage features. There is a real, if narrow, product story here: ship an MVP on filesystem caching with the PSR-6 interface as the seam, then swap to Redis when traffic justifies the ops cost. The interface abstraction is the asset; this specific implementation is disposable. A PM can fund this pattern while explicitly treating the adapter as a placeholder that will be ripped out — and should say so in the tech spec so nobody builds a dependency on it.
• Roadmap signal from the ecosystem, not the package. [READ-ONLY] in the description, zero dependents, ~70 stars, and a readme still demonstrating the Flysystem 1.x API (League\Flysystem\Adapter\Local) that was removed in 2.x/3.x. Laravel's current storage stack runs Flysystem 3.x. That gap tells us the library has effectively been superseded by symfony/cache's FilesystemAdapter within its own parent organisation. The PM takeaway: a low score here (21.6) with a middling opportunity score (47.8) is the signature of a real but already-served need — opportunity exists in the problem space, not in this artifact.

When to Consider This Package

Consider it only when all of the following hold:

• The consuming code is not running inside a Laravel application — a standalone PHP package, a worker, a CLI tool, or a shared library published across services — and already depends on psr/cache contracts.
• There is an existing Flysystem 1.x/2.x dependency in that codebase that pins you below the modern stack (in which case you are already in maintenance mode and this is a smaller problem than the rest of it).
• You need an ephemeral, per-host, dev/staging-only cache for read-heavy, low-concurrency workloads — build artifacts, template fragments, CLI memoization — where a Redis instance is genuinely disproportionate.
• You are willing to accept the adapter as a deliberately disposable placeholder with a documented exit to Redis or symfony/cache.

Look elsewhere when any of the following is true — which, for a Laravel product, is almost always:

• You are on Laravel. Use the native file driver for local/single-server caching and redis/memcached for anything production-facing. Native implementation gives you putMany, increment/decrement, tags via store implementations, php artisan cache:clear, and framework-level observability with no custom driver class to maintain.
• You need horizontal scale or high throughput. Filesystem caching cannot be shared across hosts, has no atomicity guarantees for concurrent writes on the same key, and serialization plus disk I/O is materially slower than in-memory stores for anything above ~1MB per item.
• You need maintenance guarantees. Zero dependents, no active issue triage, and a Flysystem API mismatch with the current Laravel stack means any bug you hit is yours to fix in a read-only repository. For a production dependency, that's an unacceptable support posture — symfony/cache's FilesystemAdapter is the supported equivalent and offers PSR-6 and PSR-16 side by side.
• The real need is tags, hierarchy, or namespacing. The readme defers all of that to shared php-cache.com documentation, which adds a docs dependency for behavior that Laravel's cache tags already provide.

How to Pitch It (Stakeholders)

To executives — the short version: "We evaluated a third-party filesystem caching library and are recommending we don't adopt it. Laravel already does this natively, so adopting it would mean extra code, an unsupported dependency, and a rewrite later, for zero user-visible benefit. The only scenario where it helps is if we spin out a standalone PHP service that needs a cache — and even then it's a short-term bridge, not a foundation. Net effect: no cost, one risk closed, and one less thing to maintain."

To engineering — the framing: "This is a PSR-6 pool over Flysystem, archived/read-only, with no dependents and a readme that still shows the Flysystem 1.x Adapter\Local API — which means it does not line up with Laravel's Flysystem 3.x stack out of the box. Integrating it requires a custom Cache\Store wrapper registered in a service provider, which adds a maintenance surface and an unverified compatibility risk against Laravel's expected cache behaviors (putMany, increment, tag flushing) in exchange for nothing the file driver doesn't already give us. If a non-Laravel service needs a filesystem cache, use symfony/cache's FilesystemAdapter — it's the supported successor from the same lineage. If you're prototyping and just need something, use Cache::store('file') and move on. Revisit only if we hit a genuine PSR-6 interop requirement with a pinned Flysystem 1.x/2.x consumer, and treat it as a spike, not an adoption."