Array Adapter Laravel Package

Product Decisions This Supports

• Build vs. buy vs. use-native — the first real decision. Laravel already ships an in-memory array cache store that works through the Cache facade with zero new dependencies. This package only earns its place if we specifically need a PSR-6 CacheItemPoolInterface, which Laravel's native store does not provide. Framed correctly, the decision is "do we need a PSR-6 interop shim?" — not "which cache should we run?"
• Test infrastructure and CI economics. If a service or third-party SDK type-hints a PSR-6 pool, this package lets us run deterministic, isolated tests with no Redis or Memcached container in the pipeline. The measurable wins are CI minutes, container orchestration overhead, and elimination of cross-test state leakage — tangible in engineering hours and flake rate.
• Spike scoping and roadmap sequencing. It lets us prototype cache semantics (key design, invalidation flow, TTL assumptions, hit/miss behaviour) behind an interface before we commit to a managed cache tier. This sequences the roadmap correctly: prove the feature, then size the infrastructure, rather than provisioning cache capacity for an unvalidated feature.
• Vendor and abstraction strategy. If more than one internal library — or a plausible framework migration — depends on PSR-6, this becomes the cheapest possible test binding in a chain whose production end is a PSR-6 Redis/Memcached pool. That is a genuine architectural hedge, and it is worth writing down as such rather than discovering it later.
• Dependency risk register entry. 56 stars, zero dependents, release notes that read "see changelog," a repo marked [READ-ONLY] as a split of php-cache/cache, and a coverage badge pointing at the wrong repository. This is a low-blast-radius, low-maintenance dependency — acceptable scoped to require-dev, unacceptable as an anchor for production architecture. Recording it explicitly prevents a future "why is this in here?" audit cycle.
• Explicit non-decision — this is not a performance lever. It does not reduce cost, latency, or database load in production. Anyone pitching it as a caching improvement should be redirected immediately; mispositioning it is the most likely way this evaluation goes wrong.

When to Consider This Package

Adopt it (dev-only) when all of the following are true:

• You have grepped the codebase and confirmed at least one first-party or vendor component type-hints Psr\Cache\CacheItemPoolInterface — the answer to this question decides the whole evaluation.
• You want that code tested in isolation without standing up cache infrastructure in CI.
• You are willing to bind the interface in the container rather than referencing ArrayCachePool by concrete class, so the test double can be swapped for symfony/cache or a real PSR-6 pool without touching domain code.
• You have verified the PHP constraint covers your CI matrix and run a PSR-6 conformance suite once.

Look elsewhere — or do nothing — when:

• You are a standard Laravel shop with no PSR-6 code. Use the native array store for tests and close the evaluation. Every added dependency is a future upgrade tax; this one buys nothing if the interface is never used.
• You actually want a framework-agnostic PSR-6 baseline. symfony/cache's ArrayAdapter is PSR-6 and PSR-16, actively maintained, and has Redis/filesystem siblings behind the same interfaces — a live upgrade path rather than a dead end.
• There is any chance of production use. State dies with the request, nothing is shared across processes, and in Octane/queue workers the pool accumulates without eviction. Silent cache misses in production present as a performance regression, not a config error — the most expensive failure mode on the table.
• You need TTL semantics you can trust in assertions. Lazy expiration means tests can pass against this pool that would fail in production.
• You need a support contract or a stated PHP support window. There is none, and the read-only split means local patches require a fork.

How to Pitch It (Stakeholders)

To executives: This is a small, free, MIT-licensed test utility — not a caching platform. It lets engineers test cache-dependent code without running cache servers in CI, which trims pipeline cost and flakiness. It carries no production risk because it will never run in production; the total exposure is one dev dependency that can be swapped with a one-line binding change. Approve it as a scoped engineering-hygiene decision, not a strategic bet.

To engineering: Use it as a dev-only PSR-6 test double, and only where PSR-6 is actually type-hinted. Bind Psr\Cache\CacheItemPoolInterface in the container; never reference ArrayCachePool by concrete class outside the test base class and service provider. Enforce that boundary with an architecture test (ban the namespace outside tests/) so it cannot drift into a production code path during a "temporary" fix. Where PSR-6 is required and the package must survive long-term, prefer symfony/cache's ArrayAdapter for its maintained upgrade path.

The one-paragraph decision to record: We will use Laravel's native array store as the default test cache. We will add cache/array-adapter as a dev dependency only where PSR-6-typed code exists, always behind a container binding, with a documented sunset trigger: if upstream PHP support lags our CI matrix, swap the binding to symfony/cache — no domain code changes required. That framing keeps the answer cheap to reverse, which is the only thing that matters for a dependency this small.