Cache Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. borrow for cross-cutting concerns. This bundle is a pattern reference, not a dependency recommendation. It answers the recurring question "should declarative, annotation-driven caching be a first-class capability in our service layer?" with a working proof that the pattern is feasible in a Symfony DI container — and, given 19 stars, 0 dependents, and a last release in March 2023, with equally strong evidence that the ecosystem has not validated this implementation.
• Framework direction and stack consistency. The package is a Symfony bundle, not Laravel — it depends on Symfony's container/service-scanning model, ocramius/proxy-manager, and PHP 8 attributes. If our target surface is Laravel, this is a non-starter and the decision is a straight "no"; if we maintain Symfony services, it becomes a narrow legacy-modernization question. Confirm the stack before spending any evaluation budget.
• Caching architecture and invalidation strategy. The bundle caches method return values keyed per service method, stored in any PSR-6 backend. That supports a roadmap decision between declarative per-method caching (fast to add, weak invalidation story) and explicit cache layers with tag-based invalidation (symfony/cache TagAwareAdapter) — the former is a velocity play, the latter an operational one.
• Velocity experiment scoping. If we want to test whether declarative caching measurably reduces boilerplate and duplicate key-building logic in a bounded service set, this is a cheap spike candidate to fork and vendor for one sprint, not a rollout candidate.
• Technical-debt intake policy. The package transitively pins a deprecated proxying approach (ocramius/proxy-manager's successor is friendsofphp/proxy-manager-lts). Adopting it is a concrete test case for whether our dependency policy tolerates unmaintained, single-maintainer libraries — a decision we will otherwise keep relitigating.
• Not supported: vendor due diligence for security-sensitive caching (auth tokens, PII), or anything requiring a supported SLA. Zero dependents means zero field reports.

When to Consider This Package

Consider it only when all of the following hold:

• The codebase is Symfony, not Laravel, and uses container-managed services (not Laravel's Cache facade or middleware).
• You are on a legacy Symfony 4.x/5.x app where touching dozens of service methods to inject CacheInterface and hand-roll keys is a real cost, and an annotation/attribute drop-in buys measurable time.
• You have a PSR-6 backend already provisioned (Redis/Memcached/APCu) and accept method-level keys as your invalidation granularity.
• You are willing to vendor the code and own it — audit the proxy generation, add tests, and plan a migration path — because upstream activity stopped in early 2023.
• You treat it as a time-boxed experiment with a stated exit criterion, e.g. "measure cache-hit rate and boilerplate reduction on two services within one sprint."

Look elsewhere — or build nothing — when:

• The stack is Laravel. Use Cache::remember, response-cache middleware, or route-level cache middleware instead.
• You are on modern Symfony (6.4+/7.x). Symfony now ships a native #[Cache] attribute plus symfony/cache contracts; adopting a third-party annotation bundle for the same job adds risk for no capability.
• You need tag-based or event-driven invalidation across related entities. Per-method keys will not express it; use TagAwareAdapter explicitly.
• Your caching surface is HTTP responses. symfony/http-cache / Varnish is the correct layer, not service proxies.
• You require active maintenance, security review, or a support path. 0 dependents, ~19 stars, and a stale release mean no upstream safety net and no community signal that breakage gets caught by anyone but you.
• PHP annotations are the mechanism you want. Attributes are the future; an annotation-first bundle signals a codebase you may be inheriting rather than choosing.

How to Pitch It (Stakeholders)

For executives: A small open-source caching add-on that lets developers mark service methods and get caching automatically, instead of writing cache lookups by hand. It could save a few days of boilerplate on the right kind of legacy app. It is not a strategic adoption: roughly 19 stars, no downstream projects relying on it, and no release since March 2023. Recommendation is to treat it as a design reference and a one-sprint spike at most — the expected saving is modest and the carrying cost (we own the code, plus a deprecated proxy library) is real. Modern frameworks now cover this natively, so the durable answer is to standardize caching on the framework's built-in mechanism rather than adopt a niche package.

For engineering: The mechanism is a compile-time scan of service methods for a cache attribute, generation of a proxy-manager subclass per service, and an overridden getCached call that derives a key and reads/writes any PSR-6 pool. The idea is sound and readable; the implementation is not something we should depend on. Concrete risks: ocramius/proxy-manager is superseded by friendsofphp/proxy-manager-lts, so Composer conflicts are likely on modern PHP; proxies on services interact badly with final classes and typed properties; and the per-method key scheme gives us no tag-based invalidation. If we want this ergonomics, the two viable routes are (1) Symfony's native #[Cache] attribute on 6.4+/7.x, or (2) ~150 lines of our own attribute plus a decorator, which we fully control. If we proceed with a spike anyway, vendor the source, pin it, and put a removal ticket on the board at the same time.

For the framework decision-makers: Note the mismatch explicitly — this is a Symfony bundle, so it does not apply to a Laravel roadmap. If the question behind the question is "how do we get cheap, consistent caching across services," answer it with a team-level convention and the framework's native primitives; do not answer it with a package at this maturity level.