Psr 6 Doctrine Bridge Laravel Package

Product Decisions This Supports

• Legacy Doctrine cache migration — this is a transitional shim, not a strategic dependency. It buys time: your Doctrine ORM components keep working against Doctrine\Common\Cache\Cache while the underlying storage moves to a PSR-6 pool you already operate (Redis, Memcached). Frame the decision as "how long do we need the shim, and what replaces it," not "which cache library do we standardize on."
• Cache consolidation / cost reduction — the real value is retiring a second cache backend. If Doctrine has its own FilesystemCache or APCu instance alongside a Redis layer, this collapses two systems into one, cutting one operational surface, one set of TTL configs, and one thing to monitor.
• Build vs. buy: buy, but cheaply — the bridge is a thin adapter (contains/fetch/save/delete/getStats mapping) with no transitive dependencies and an MIT license. The build cost in-house is low, so the adoption decision should hinge on maintenance and trust, not capability. Realistic options: adopt the package, vendor a fork, or write ~100 lines yourself. All three are defensible; pick based on how much you care about upstream fixes.
• Roadmap sequencing for Doctrine ORM upgrades — this package only matters if you have Doctrine in the stack. Laravel does not ship Doctrine ORM; it ships Eloquent. That makes the addressable population small: teams running Doctrine alongside or instead of Eloquent (legacy migrations, Symfony-influenced teams, Doctrine-dependent third-party packages). If that's not you, this is a non-decision.
• Use cases worth validating before committing — Doctrine metadata caching, DQL query result caching, and third-party libraries that hard-code Doctrine\Common\Cache\Cache. These are the only places the bridge earns its keep.

Key PM caveat to surface in any decision doc: Doctrine\Common\Cache\Cache is deprecated and was removed in doctrine/cache 2.0; Doctrine ORM 3 uses PSR-6 natively. The bridge's useful lifespan is bounded by how long you stay on the legacy interface. Treat this as a dated bet with a scheduled exit, not a foundation.

When to Consider This Package

Adopt when:

• You run Doctrine ORM (or a Doctrine-dependent library) and it expects Doctrine\Common\Cache\Cache, and you want that traffic on a PSR-6 pool you already run in production.
• You need to change cache backends (e.g., file → Redis) without touching Doctrine configuration or ORM code paths.
• The work is scoped and time-boxed: a migration sprint with a defined exit to native PSR-6 once Doctrine is upgraded.
• You're comfortable owning the code. Low stars, zero dependents, and a single-maintainer-style community project mean you should assume you may fork it. MIT makes that cheap; budget for it anyway.

Look elsewhere when:

• You're a standard Laravel/Eloquent shop. No Doctrine, no Cache interface, no problem this solves. Use Illuminate\Cache directly.
• You're already on Doctrine ORM 3 / doctrine/cache 2.x. The interface this bridges no longer exists. Adopting it would be adopting a solution to a problem you've already outgrown.
• You need anything beyond get/set/delete. No tag support, no namespacing semantics matching Doctrine's, no cache warming, no events. If your cache strategy depends on invalidation groups, this bridge will fight you.
• You need vendor support or an SLA. 15 stars, 0 dependents, and no evidence of broad production use means you are the support contract. If procurement or security review requires a maintained upstream, this fails that bar.
• You can't verify compatibility yourself. Confirm it works against your exact Doctrine version and PHP version before it enters the roadmap — do not accept the README as evidence. The release history signals activity but the docs say nothing about supported version ranges.

Decision gate: before writing a line of code, answer two questions. (1) Which Doctrine version are we on, and when do we leave it? (2) Does anyone on the team own this if upstream goes quiet? If either answer is "don't know," don't adopt yet.

How to Pitch It (Stakeholders)

For executives — one paragraph, framed as risk reduction with a defined end date: "We have a small piece of technical debt: one part of our stack still uses Doctrine's deprecated caching interface while everything else has moved to a modern, standard cache layer. This package is a ~100-line MIT-licensed adapter that lets that legacy code use our existing cache infrastructure, so we can shut down a redundant cache system and stop paying to run and monitor two of them. It's low cost and low risk — the code is trivially replaceable if the project stalls — but it is explicitly a bridge, not a destination. I'd recommend approving it as a time-boxed migration with a target date to remove it once we finish the Doctrine upgrade."

For engineering and architecture:

• What it is: a DoctrineCacheBridge implementing Doctrine\Common\Cache\Cache on top of any Psr\Cache\CacheItemPoolInterface. No transitive dependencies, MIT, ~500 LOC.
• Why now: it decouples Doctrine's cache storage from Doctrine's own cache implementations, which lets one Redis/PSR-6 pool serve both Doctrine and application caching, and removes a backend from the ops surface.
• The honest trade-offs: no tag support (Doctrine's interface can't express it), TTL semantics differ between the two APIs (Doctrine timestamps vs. PSR-6 expiresAfter), and exception types may not map cleanly — we should test error paths, not just happy paths.
• The strategic risk: Doctrine deprecated Doctrine\Common\Cache\Cache and removed it in doctrine/cache 2.0. This package solves a problem that is actively disappearing. Recommendation: adopt as a migration accelerant with a documented removal ticket, and do not let it become a permanent layer. If we're already on Doctrine ORM 3, skip it entirely.
• Ask before committing: a one-day spike to confirm version compatibility, benchmark overhead versus the current cache implementation, and document the rollback path. If the spike is clean, this is a safe, reversible decision.

For developers: "Wrap your PSR-6 pool in DoctrineCacheBridge and hand it to Doctrine — that's the whole integration. Good for unblocking a legacy upgrade or getting Doctrine onto Redis without a refactor. Don't reach for it for new code, and don't expect tags or advanced invalidation. Verify it against our Doctrine version first; the README doesn't tell us what's supported."