Array Adapter Laravel Package

Technical Evaluation

Architecture fit cache/array-adapter is a PSR-6/PSR-16 in-memory pool backed by a PHP array. From a TPM lens, the key architectural constraint is a protocol mismatch with Laravel's cache layer: Laravel's Cache facade and Illuminate\Contracts\Cache\Repository are PSR-16/Store-shaped, not PSR-6. This package implements Psr\Cache\CacheItemPoolInterface, so it cannot be dropped in as a Laravel cache store without a custom Store wrapper. That means the package is not a caching strategy — it is an interop boundary artifact.

The second constraint is redundancy: Laravel already ships an array store (CACHE_STORE=array) that is request-scoped, TTL-aware, and zero-config. For most Laravel work, this package is architecturally unnecessary. The narrow but legitimate fit is code that type-hints PSR-6 — third-party SDKs, framework-agnostic domain libraries, or an internal abstraction deliberately written against PSR-6 for portability.

Integration feasibility Half a day to a day, dev-only, low value at the start. composer require --dev cache/array-adapter plus a single container binding in the test base class ($this->app->instance(CacheItemPoolInterface::class, new ArrayCachePool())). It is not feasible as a production store under any configuration — state dies with the request, there is no cross-process sharing, and there is no eviction by default.

Technical risk Dominant risk is organizational, not technical. The class is trivially instantiable, so it can drift into a production code path during an expedient fix. Secondary risks:

• Read-only split repo. The GitHub repo is a [READ-ONLY] subtree split of php-cache/cache; fixes land upstream in a project we are not tracking. No independent velocity.
• Thin documentation surface. Maturity is "readme, releases" only. Releases 0.4.2 through 1.2.0 all read "See change log," and the changelog is not in this repo — upgrade-impact analysis is guesswork.
• Low ecosystem signal. 56 stars, 0 dependents. Minimal adoption means compatibility regressions surface in our CI, not upstream's.
• Long-running process memory. Under Octane, Swoole, or queue workers, the pool persists across requests/jobs and grows unboundedly — a slow leak rather than a clean failure.

Key questions a TPM must get answered before committing

• Do we have first-party or vendor code that actually type-hints PSR-6? A grep for CacheItemPoolInterface / Psr\Cache is the single decision gate. If zero hits, close this as "not needed."
• What is the real maintenance status and PHP-version policy of the php-cache/cache monorepo? Metadata is inconsistent — the package record's last release date conflicts with prior internal notes. One of these is wrong and it changes the risk profile materially.
• Is our caching abstraction deliberately framework-agnostic (PSR-6), or Laravel-coupled (PSR-16/facade)? This answer decides adopt vs. reject.
• Who is the internal owner if the upstream goes quiet?

Integration Approach

Stack fit Recommend --dev only, scoped to the test suite, and only if the PSR-6 question is answered "yes." For everything else, use the native array store as the dev/test default — no new dependency, TTL-correct, already understood by the team.

Where PSR-6 is genuinely required, evaluate symfony/cache's ArrayAdapter as the baseline instead: it is PSR-6 and PSR-16, actively maintained, and has first-class Redis/filesystem siblings behind the same interfaces. That gives a credible production migration target. Choosing this package over symfony/cache buys only a marginally smaller dependency and costs a dead-end upgrade path.

Migration path Position the package as the start of an interface chain, not the destination:

• Bind Psr\Cache\CacheItemPoolInterface in the container. Never reference ArrayCachePool by concrete class outside the service provider and the test base class.
• Dev/test: ArrayCachePool (or ArrayAdapter).
• Production: swap the binding to a PSR-6 Redis/Memcached pool behind the same interface. No domain code changes.
• If a component needs the Laravel facade instead, that is a separate, deliberate bridge — not something to improvise later.

Compatibility Two checks before committing budget:

• PHP version support. Confirm the composer.json require constraint covers our CI matrix (current PHP 8.x minors) and pin it. Given the thin release history, treat each PHP minor bump as a re-check task in the upgrade runbook.
• PSR-6 conformance. The README claims PSR-6; there is no advertised conformance suite in this repo. Run php-cache/integration-tests against it once in CI so spec gaps surface as a test failure rather than as a framework bug during a release.

Sequencing

1. Grep the codebase (including vendor) for CacheItemPoolInterface / Psr\Cache. Assign an engineer, one-day timebox.
2. If zero hits: record the decision as "use Laravel's array store; do not add this dependency," and close the ticket.
3. If hits exist: add as dev dependency, bind the interface in the test base class, verify PHP constraint, run PSR-6 integration tests once in CI.
4. Only after the seam is exercised in tests, introduce a production PSR-6 adapter behind the same binding. Do not sequence production work ahead of the test binding.

Operational Impact

Maintenance Near-zero day-to-day cost, non-zero stewardship cost. Because it is a read-only split, we cannot patch locally without forking or vendoring. Stand up a quarterly review: is the upstream monorepo still releasing? Does it support the latest PHP minor? If either flips, remediation is a one-line binding change to symfony/cache — which is precisely why the interface-binding discipline matters more than the package choice.

Support No vendor, no SLA, no commercial backing. Community support is a low-traffic Gitter channel tied to the php-cache organisation. Assign internal ownership to the platform/backend team that owns the test harness, with the explicit expectation that "support" means "we replace it if it breaks," not "we file an issue and wait."

Scaling Not applicable in the production sense — the pool does not share, persist, or scale. The scaling concern that does apply is intra-process: under Octane/Swoole workers, entries accumulate across requests since eviction is only on write past an optional cap. Two mitigations to budget for: (a) an architecture/static-analysis rule (PHPStan or an Ark test) banning the Cache\Adapter\PHPArray namespace outside tests/, and (b) explicit clear() in long-running test fixtures.

Failure modes to plan against

• Silent cache misses in production — if the array pool is wired into a live path, every read misses and uncached load lands on the database. Presents as a performance regression, not a config error. Most expensive and least obvious.
• Memory exhaustion in long-running processes with no eviction.
• Stale-item surprises in tests — lazy expiry means an expired item may still be readable, so TTL logic can pass tests it shouldn't. Never write TTL assertions against this pool expecting production expiry semantics.
• Dependency rot at PHP upgrade time, surfacing as a Composer resolution failure in CI. Cheapest failure, and the reason to keep the surface small.

Ramp-up Minutes. composer require --dev cache/array-adapter, new ArrayCachePool(), standard PSR-6 methods (getItem, save, hasItem, clear). Any PHP engineer is productive on day one. The real onboarding need is not "how to use it" but "when not to use it" — capture that as a one-paragraph ADR plus a code-level guard rather than relying on tribal knowledge.

Recommendation: Do not adopt as a platform dependency. Adopt selectively as a dev-only test binding if and only if PSR-6-typed code exists; otherwise standardize on Laravel's native array store for tests, with symfony/cache ArrayAdapter as the PSR-6 baseline where framework-agnosticism is a stated requirement. The package is technically sound and operationally trivial, but read-only split status, empty changelogs, zero dependents, and direct overlap with Laravel built-ins make it a dependency adopted for compatibility reasons better served elsewhere.