Cache Bundle Laravel Package

Product Decisions This Supports

Short answer: none for a Laravel codebase — this is a reject, not an adopt. The diligence finding that matters most is a category error before any technical evaluation: fm/cache-bundle is a Symfony2 bundle, not a Laravel package. There is no service provider, no composer.json Laravel auto-discovery, and no compatible integration surface. Any roadmap item that assumed this could be dropped into a Laravel app is based on a false premise and should be corrected now rather than at sprint planning.

What it would have supported, and what to build instead:

• Read-heavy entity caching (the underlying product goal). The bundle wraps Doctrine ORM entity reads in a cache layer to cut database load on content-heavy pages — a legitimate performance goal for a publishing/CMS-style product. That goal is real; this implementation is not the vehicle.
• Build vs. buy vs. framework-native. For Laravel, the correct answer is a third option: framework-native. Cache::remember() / Cache::tags() over Redis, watson/rememberable for Eloquent query caching, or spatie/laravel-responsecache for full-response caching cover this use case with maintained, documented, security-patched code.
• Prioritization. Do not allocate roadmap capacity to integration spikes, compatibility shims, or a "port it" ticket. The port cost (Symfony2 → Laravel, PHP 5.x → 8.x, Doctrine → Eloquent) exceeds writing the caching layer fresh by an order of magnitude.
• Reference value only. If the team wants prior art for how to shape an entity cache (key strategy, invalidation hooks on write), reading the source for 30 minutes is the ceiling of its usefulness. Treat it as a design artifact, not a dependency.

When to Consider This Package

Adoption criteria — effectively never, and specifically not here:

• Only a legacy Symfony 2.x application pinned to PHP 5.x, already depending on this bundle, would have a reason to keep it. Even then, the correct decision is a migration plan, not continued reliance.
• Every adoption gate fails: last release 2013-10-25, repository archived, 0 stars, 0 dependents. Zero dependents is the loudest signal — it means no one in the ecosystem has validated this against a real production workload, and there is no pool of users to surface bugs or contribute fixes.
• Zero security posture. An archived 2013 PHP package has had no patching through a decade of disclosed vulnerabilities. Procurement/security review should terminate here.

Look elsewhere — always, in these concrete directions:

• Laravel: native cache repository + Redis, watson/rememberable, spatie/laravel-responsecache, model observers for invalidation.
• Symfony (modern): Doctrine's built-in second-level cache, symfony/cache PSR-6 contracts.
• Red flags to encode in your evaluation checklist so this class of package is screened out automatically: archived status, last-release age > 24 months, zero dependents, and framework major version EOL. Any one of these should block; this package trips all four.

How to Pitch It (Stakeholders)

To executives: We evaluated a candidate caching library for database performance and are recommending against it. It is a 2013 Symfony component that has been archived upstream, with no active maintainers and no adopters — it cannot be safely run in our stack, and adopting it would create a security and maintenance liability with no offsetting benefit. The cost of declining is zero; the performance goal it nominally addresses is fully covered by caching tools already in our framework and already supported. Net recommendation: close the evaluation, no budget impact, no schedule impact.

To engineering: This is a Symfony2 bundle, not a Laravel package — flagging the mismatch first so nobody burns a spike on it. Beyond that, it's archived since 2013, PHP 5.x era, zero stars, zero dependents, no security patching. Don't vendor it, don't port it, don't read it as an architectural guide unless you're specifically curious about 2013 Doctrine caching patterns. If a ticket references it as a solution, point it at Cache::remember() with Redis and model observers for invalidation, or spatie/laravel-responsecache if we want full-response caching. If the underlying concern is read load on the entity layer, that's a real conversation — let's scope it against our actual query profile rather than starting from a package.