Illuminate Adapter Laravel Package

Product Decisions This Supports

• Cache abstraction strategy (build vs. buy vs. skip). This package exists to answer one narrow question: do we let PSR-6 consumers talk to our existing Laravel cache, or do we refactor our cache layer? It is a ~100-line MIT-licensed adapter, so "buy" here costs almost nothing in licensing and code volume — the real cost is the dependency decision, not the implementation.
• Interoperability with third-party PSR-6 code. If any library in the stack expects a PSR-6 CacheItemPoolInterface (Doctrine ORM second-level cache, Symfony components, certain HTTP/SDK clients), this is the cheapest path to satisfy it without replacing Laravel's Cache facade or reconfiguring .env/config/cache.php.
• Gradual-migration roadmap item. Enables a "strangler" pattern: wrap the current Illuminate\Cache\Store today, move PSR-6-aware consumers over first, and defer any larger caching refactor. Useful as a de-risking step on a roadmap where a cache rewrite is otherwise unowned and unscheduled.
• Vendor lock-in hedge (weak, but real). Keeps application code written against PSR-6 rather than Cache:: calls, so a future move (Redis → DynamoDB, Laravel → Symfony, monolith → service) touches configuration instead of business logic.
• Test and local-dev velocity. Wrapping ArrayStore gives a deterministic, interface-based cache in unit tests, which reduces flaky test surface in suites that currently hit a real store.
• Tag-based invalidation for hierarchical data. Where the underlying store supports tags, the pool exposes them — relevant for tenant/catalog-shaped data (user:123:*, product:category:*) where key-prefix bookkeeping gets error-prone.
• What it should not support: this is plumbing, not a differentiator. It does not justify a roadmap initiative, a migration program, or a platform-team mandate on its own. Treat it as an enabling detail inside a decision someone else is already making.

When to Consider This Package

Consider it when all of the following hold:

• You run a Laravel app on a standard Illuminate\Cache store (redis, array, file, database) and want to keep it that way.
• A concrete consumer in your dependency graph requires PSR-6, and you've confirmed it doesn't accept Laravel's cache directly.
• The integration is contained — one service, one adapter instance — and testable behind a feature flag.
• You've verified compatibility with your Laravel/PHP versions yourself. Version support is not documented; the README shows two lines of usage and nothing else.
• You accept that this is a 0.x, 11-star, zero-dependent, read-only mirror package. Budget for vendoring or forking it into your own namespace, and treat upstream as a convenience, not a support contract.

Look elsewhere — or do nothing — when:

• No PSR-6 consumer exists. A pure Laravel codebase gains nothing; you'd be adding an abstraction layer to satisfy nobody.
• You need the abstraction to be a maintained platform component. Prefer symfony/cache (with its own Laravel bridge) or a first-party PSR-6 implementation you own, both of which give you versioning discipline, docs, and a security-response story this package does not demonstrate.
• You rely on Laravel-specific cache behavior — cache events, rememberForever semantics, Cache::lock(), or store-specific quirks that a PSR-6 surface won't faithfully proxy.
• Driver coverage matters. Tag support and multi-key semantics vary by store; the README doesn't publish a compatibility matrix, so anything beyond a simple key/value pool is unvalidated until you test it.
• The performance budget is tight. Overhead is likely small, but no benchmark is published — measure before committing, and don't repeat vendor-adjacent performance claims in a decision doc.
• You need release guarantees. Pre-1.0 versioning plus a read-only repo means you should assume feature requests land with you, not upstream.

How to Pitch It (Stakeholders)

For executives (one paragraph): "A small, free, open-source bridge that lets our Laravel app's existing cache serve code written against the PHP caching standard. It's roughly a hundred lines under a permissive license, so the financial and technical downside is negligible — the only cost is a decision. It's worth doing only if a specific library we already depend on demands the standard interface; otherwise it's complexity with no payoff. It does not require a project, a budget line, or a migration program — it's a configuration-level call inside work already underway. I'd recommend we make it a per-team decision with a rule attached: use it, but vendor it, so we're not dependent on a lightly maintained package."

For engineering: "This wraps an Illuminate\Cache\Store (Redis, array, file, database) in a PSR-6 pool — two lines, no changes to config/cache.php, no changes to existing Cache:: call sites. Two things to verify before merging: the store's tag and multi-key behavior matches what our PSR-6 consumer assumes, and the package is compatible with our Laravel/PHP versions, since support isn't documented. Copy the adapter into our codebase rather than taking a hard dependency — it's small enough to own, which removes the maintenance risk entirely and keeps our options open. Benchmark the pool against direct Cache:: calls if the path is hot."

For architects: "Choose this if cache-interface standardization is on the roadmap for reasons that already exist; reject it if it's being proposed as the reason to standardize. The real trade-off is a thin, unowned abstraction versus direct coupling to Laravel's cache API. Both are defensible; the wrong answer is adopting it without naming the PSR-6 consumer that justifies it."