Weave Code
Cache Bundle Laravel Package
kitano/cache-bundle
A Symfony/PHP bundle that adds annotation-driven caching to service methods, making it easy to cache expensive results with configurable keys, providers, and lifetimes while keeping application code clean.
The development has moved to a new repository: https://github.com/TheBigBrainsCompany/TbbcCacheBundle
Frequently asked questions about Cache Bundle
- Does kitano/cache-bundle work with Laravel?
- No. Despite being listed among Composer packages for PHP applications, kitano/cache-bundle is a Symfony bundle: it ships a Bundle class, a dependency-injection extension, compiler passes, kernel event wiring, and annotation-driven caching resolved through Doctrine's annotation reader with a hard dependency on jms/aop-bundle. Laravel has no counterpart for any of those artifacts, so this is not a package with a high integration cost, it is a package with no integration path.
- How do I install and configure kitano/cache-bundle?
- On Symfony 2.x you would require the package, register KitanoCacheBundle in AppKernel, enable the annotation reader, install jms/aop-bundle so annotations can be woven into service methods, and then declare providers and cacheable services in your bundle configuration. There is no Laravel equivalent: no service provider, no publishable config, and no package discovery entry. If you are working in a Laravel application, stop at composer require and do not proceed.
- Which Symfony and PHP versions does kitano/cache-bundle require?
- The bundle targets the Symfony 2.1 to 2.3 era and PHP 5.3, and it pulls in jms/aop-bundle for annotation weaving. On PHP 8.1 and later, which is the floor for Laravel 10 and 11, that vintage produces dynamic-property deprecations, removed idioms, and annotation-reader API drift with no upstream to patch any of it. It supports no Laravel version at all.
- Is kitano/cache-bundle still maintained?
- No. The maintainer has deprecated it in favour of TheBigBrainsCompany/TbbcCacheBundle, and the package description itself points there. With roughly 14 stars and zero dependents there is no production surface, no third-party issue corpus, and no implicit compatibility guarantee. Adopting a predecessor after the maintainer has publicly named a successor is very hard to defend in a design review.
- How does the bundle generate and customise cache keys?
- Cache keys are generated automatically from the cached method and its arguments by default, and you can override them through annotation configuration when you need finer control. Combined with the TTL and eviction options, this forces an explicit answer to the question of how stale a given result may be. That key-plus-lifetime model is the one genuinely portable idea in the package.
- Can I reuse just the cache adapters in a Laravel application?
- Only in a very narrow sense. The portable asset is the adapter and abstraction layer beneath the bundle, and that layer predates PSR-6 and PSR-16 as the default contract. Laravel's Cache facade with tagged Redis or Memcached stores plus a repository decorator reproduces the same behaviour in tens of lines with first-party support, so there is no route here cheaper than the native build.
- What is the best Laravel replacement for annotation-driven method caching?
- Laravel's Cache facade is the replacement, wrapped in a small Cacheable trait or a repository decorator so the original ergonomics survive. Carry the key and TTL in PHP attributes, resolve them inside the decorator, and back it with Redis so tag-based flushing stays cheap. If you specifically need framework-neutral PSR-6 or PSR-16 interchangeability, symfony/cache is the maintained answer.
- How should I handle TTL and cache invalidation in a Laravel port?
- Express the TTL per surface rather than globally, because pricing, inventory, profile, and feed data all have different tolerances for staleness, and that is a product decision rather than a technical default. In the decorator, call Cache::forget or flush a tag inside the same transaction that writes the underlying data. A documented staleness SLA per surface is worth more than any code you lift from the bundle.
- How do I test cached method results in a Laravel app?
- Switch the cache store to the array driver in your test environment so cached calls never reach Redis, and use Cache::spy() to assert that a result was stored on the first call and reused on the second. Freeze time with Carbon::setTestNow or the travel helper to prove the TTL actually expires, and assert that writes evict the right key or tag. Cover the invalidation path explicitly, since that is where caching bugs actually live.
- What are the production risks of adding this package to a Laravel project?
- The risks are concentrated in provenance rather than code quality: a maintainer-issued deprecation, a Symfony 2.x vintage that will not run cleanly on PHP 8.1, and zero ecosystem validation behind it. There is also no upstream to patch a security or compatibility issue, which means you would own any fork indefinitely. For a Laravel service the practical risk is simpler still: the package cannot land at all.
Weaver
How can I help you explore Laravel packages today?