- Can I use emag-tech-labs/annotation-cache-bundle in a Laravel application?
- No. Despite the Composer package name, this is a Symfony bundle, not a Laravel package. It works by registering a compiler pass against the Symfony DI container, scanning service definitions for a @Cache annotation or #[Cache] attribute, and swapping in generated proxy classes. Laravel has no equivalent definition-scanning or container compile phase, so there is nothing for the bundle to hook into. Adding it to a Laravel composer.json gives you dead weight plus an abandoned transitive dependency.
- How does the Annotation Cache Bundle actually work?
- On container compile, the bundle scans the methods of your configured services looking for the Cache annotation or PHP 8 attribute. For every matching service it generates a subclass proxy with ocramius/proxy-manager that extends the original class, includes a CacheableClassTrait, and overrides the annotated methods. Each overridden method calls getCached, which builds a cache key, reads from a PSR-6 pool, and on a miss calls the original method and stores the result. A CompilerPass then replaces the original service definition with the proxy.
- Does the package support PHP 8 attributes as well as annotations?
- Yes. The bundle supports both the classic @Cache docblock annotation and the PHP 8 #[Cache] attribute syntax. Both are detected during the same service method scan, and both produce the same proxy behaviour. The attribute form avoids the doctrine/annotations dependency path, which is the better option if you are on PHP 8 or newer.
- Which cache backends does it support, and does it work with Laravel's cache?
- It works with any class implementing the PSR-6 Caching Interface, such as a simple array pool, Redis, or Memcache. Laravel's cache layer is PSR-16-shaped rather than PSR-6, so wiring it in would require an adapter or a completely separate pool. That fragments your cache configuration, prefixing, and observability away from config/cache.php. Laravel developers are usually better served by Cache::remember() against the native store.
- Is there a Laravel service provider or facade for this bundle?
- There is no service provider, no facade, no Laravel container binding, and no awareness of config/cache.php. Integration is entirely through Symfony Flex or manual Symfony bundle registration in bundles.php. Making it work in Laravel would mean running a Symfony DI container inside your app or rewriting the annotation scan against Laravel's container, which is effectively writing a new package.
- How are cache keys generated, and can I namespace or invalidate them safely?
- Keys are derived from the annotation details plus the serialized method arguments, so identical calls hit the same entry. That approach can silently collide across services and will fail outright on non-serializable arguments such as closures, resources, or many entity graphs. There is no documented key versioning or namespace strategy, so safe invalidation becomes something you own rather than something the bundle gives you. Return values must also be serializable, which rules out a large class of realistic return types.
- What are the limitations of proxy-based method caching?
- Proxies cannot wrap final classes, final or private methods, or readonly state, so an ordinary refactor can turn into a container compile failure. Caching also changes method semantics silently: callers cannot tell they are receiving stale data, and side-effecting or non-deterministic methods become correctness bugs rather than performance wins. Combined with key derivation from serialized arguments, these constraints mean the pattern works best on small, pure, idempotent read methods.
- Is the package actively maintained, and does it support Symfony 6 and PHP 8.2?
- Signals point to a dormant internal-origin project: the last release was 2023-03-30, it has roughly 19 GitHub stars and zero dependents, and CI still targets Travis. The bigger blocker is the dependency on ocramius/proxy-manager, which is abandoned upstream and superseded by friendsofphp/proxy-manager-lts, constraining the PHP and Symfony versions you can use. There is no published roadmap for a maintained proxy-manager replacement, so verify version support yourself before relying on it.
- What should Laravel developers use instead of this bundle?
- Use Cache::remember() at the repository or service boundary for explicit, readable caching. For declarative behaviour, bind decorator classes in a service provider so the caching concern stays out of your business logic while remaining visible in the container. If the goal is HTTP-level caching, spatie/laravel-responsecache covers that directly. All three keep you inside Laravel's cache configuration, tagging, and monitoring.
- Is it safe to run in production?
- For a real Symfony codebase it is plausible but dated, and the abandoned proxy-manager dependency plus the 2023 release date are meaningful maintenance risks. For a Laravel codebase it should not be adopted at all, because there is no supported integration path and the PSR-6 pool would sit outside Laravel's cache layer. Treat it as a pattern reference for declarative caching and implement the equivalent with native Laravel constructs. If you inherit it in a Symfony app, pin your versions and plan a migration to friendsofphp/proxy-manager-lts.