Taggable File Cache Laravel Package

Product Decisions This Supports

• Cache infrastructure spend (build vs. buy vs. add a service): This package is the shortest path to tagged cache invalidation without standing up Redis or Memcached. It frames the recurring product decision — "do we add a cache service to the stack, or stay file-based?" — which matters most for single-node or small-footprint deployments where a managed Redis instance is real monthly cost and a new operational dependency.
• Grouped-invalidation feature work: Any roadmap item that needs to drop a family of cached entries rather than a single key — feature-flag snapshots, navigation/menu fragments, CMS blocks, localized content bundles, API response fragments, dashboard widgets. Cache::tags([...])->flush() is the product-level primitive these features require, and the package supplies it on top of Laravel's existing file store.
• The honest build-vs-buy framing: Buy the pattern, not the dependency. The mechanism (tag-index files alongside cached payloads) is small and well understood; roughly 100 lines of in-house code reproduces it on Laravel's file store with no external maintainer. The 1.0.0 tag is a statement of intent, not evidence of a maintained project — one author, zero dependents, one release ever (2018-02-16), no compatibility matrix, no CI or security history. The real options remain Redis, in-house tag layer, or no tags at all.
• Roadmap sequencing: If a Redis commitment is already on the roadmap within 2–3 quarters, adopting a file-based tag layer now buys little and creates a migration later. If Redis is not on the roadmap, this pattern (in-house or vendored) is the right shape for the caching work.
• Deployment topology as a product-correctness input: File cache is node-local, so tag flushes only invalidate the machine that performed them. On a multi-server or autoscaled deployment, stale content can be served from sibling nodes. This effectively caps the approach to single-node or sticky-routed environments unless the product accepts visible inconsistency.
• Deprecation and ownership planning: With ~0 dependents and a single release event, any adoption is de facto an internal fork. Record it in the tech-debt register as an owned component, not a third-party line item. If vendored, 1.0.0 is the natural pin — but pin the commit SHA or a vendored copy, not a floating registry constraint.

When to Consider This Package

Reasonable to evaluate when:

• The application runs on a single app server (or all traffic is sticky to one node), so node-local cache invalidation is acceptable.
• We need coarse grouped invalidation for a handful of feature areas and single-key Cache::forget() is genuinely insufficient.
• Adding Redis/Memcached is off the table — cost, ops appetite, compliance, or a hosting environment that doesn't offer it.
• Cached values are small and regenerable, so a stale or orphaned tag index is a performance problem, not a data-loss problem.
• We are willing to vendor or fork the code and assign an internal owner who can read and patch it. The 1.0.0 label makes this slightly more palatable — it signals the author considers the API surface settled — but it supplies no support commitment.
• The work is time-boxed and reversible — a spike or a behind-a-flag experiment, not a load-bearing dependency on a critical path.

Look elsewhere when:

• We run multiple app servers, autoscaling, or containers — use Redis (Laravel's native taggable store); correctness beats infrastructure simplicity here.
• We need an actively maintained dependency with a support policy, security advisories, and a compatibility matrix against future Laravel majors. A first-ever 1.0.0 from 2018 with notes reading "First release" means the next Laravel major is our problem.
• The invalidation is correctness-critical (entitlements, pricing, permissions). Tag-index bookkeeping is exactly the kind of thing that fails silently.
• The workload is high-throughput — disk I/O per read and per tag operation is a regression versus in-memory stores.
• We are standardising on a cache abstraction across services; a bespoke file-based driver fragments the platform story.
• The real need is just a TTL — use plain file cache and skip tags entirely.

How to Pitch It (Stakeholders)

For executives (30-second version): We have a small caching gap: we can expire individual cache entries, but not whole groups, and closing that gap today means either buying a Redis service or writing a little code. An open-source package does the group-expiry trick on top of plain files — no new infrastructure, no new vendor contract. It just shipped its first 1.0.0 release, which is a good sign for API stability but is not the same as a maintained project: no support policy, no security history, one author, last release in 2018. My recommendation is unchanged — take the idea, not the dependency: implement the same tag-index pattern in-house behind Laravel's cache API in a day or two, or vendor 1.0.0 as a frozen, internally owned copy if we want the head start. We get the product capability with no maintenance hostage and no infrastructure spend. Redis remains the right answer the moment we go multi-server — and that's the decision to keep on the roadmap.

For engineering:

• What it is: a drop-in taggable store for Laravel's file cache driver, which natively cannot support tags. Tag-index files track membership so Cache::tags([...])->flush() works without an external cache. Blast radius is confined to the cache layer — one store class, one driver registration, config — and it sits behind the framework-native Cache::tags() API, so the exit to Redis is a driver swap, not a refactor.
• What changed in 1.0.0: a version bump and a one-line release note ("First release"). No stated breaking changes, no new features, no compatibility matrix, no prior release to be backwards-compatible with. Treat it as newly declared stability, not demonstrated stability. It also dates to the Laravel 5.5/5.6 era, so assume constraint conflicts and porting work.
• Why we're not blindly composer require-ing it: single maintainer, zero dependents, no CI evidence, no security history, no declared Laravel/PHP support range. Adopting it means we fork on the first breaking change — and we'll be the ones who discover that break.
• What we want instead: reimplement the tag-index approach internally — bounded scope, fully tested, inside our own cache abstraction. If we later move to Redis, the call sites stay identical.
• If we do spike or vendor: pin to 1.0.0 — exact or a shipped/committed copy, not ^1.0. Run it in a scratch branch against our locked framework version and exercise flush-by-tag under concurrency (parallel writes plus a flush, assert no stale or orphaned entries) before it reaches staging. Budget 1–3 engineer-days to port and test, roughly half a day per quarter to keep alive, spiking on Laravel majors.
• Non-negotiables: one named internal owner, a documented removal path, tests covering tag-flush correctness, and an explicit tech-debt-register entry that this component is ours to maintain.
• Hard constraint to design around: node-local cache means node-local invalidation. Any move to horizontal scaling reopens this decision — make that a re-assessment trigger alongside any Laravel major upgrade.