- What is cache/tag-interop used for?
- cache/tag-interop defines two PSR-6 extension interfaces: TaggableCacheItemPoolInterface for pools that support tags and TaggableCacheItemInterface for their items. It contains no implementation, service provider, or Laravel integration. You still need a cache pool or adapter that implements the interfaces.
- Does cache/tag-interop add tag support to Laravel's cache?
- No. Laravel's Illuminate\Cache is not built on PSR-6 and already provides Cache::tags() on Redis, Memcached, and array stores. This package only defines interfaces and cannot make file or database stores taggable. Adopting it in Laravel means bridging or running a parallel PSR-6 cache abstraction.
- How do I install cache/tag-interop with Composer?
- Run composer require cache/tag-interop:^2.0. Version 2 extends psr/cache 3 and requires PHP 8 or newer. After installing, code against TaggableCacheItemPoolInterface and TaggableCacheItemInterface, but remember you must supply a concrete tagged pool implementation.
- Which PHP and Laravel versions are supported by cache/tag-interop?
- Version 2 targets psr/cache 3 and PHP 8+, version 1.1.0 was the psr/cache v2 bridge, and version 1.0.x used PHPDoc return types that can misbehave under modern autoloading and static analysis. The package is framework-agnostic, so Laravel version support depends on your adapter and PHP version, not on cache/tag-interop itself.
- Do I need cache/tag-interop to use Cache::tags() in Laravel?
- No. Cache::tags() is a native Laravel API available on Redis, Memcached, and array stores; file and database stores do not support tagging. cache/tag-interop is for PSR-6 interoperability, not for enabling or changing Laravel's native tagging behavior. Use it only when you deliberately need a PSR-6 tag contract.
- How do I implement TaggableCacheItemPoolInterface in a Laravel application?
- You must provide a class that implements the PSR-6 pool methods plus tag and invalidateTags behavior, along with items implementing TaggableCacheItemInterface. Practical options are wrapping an existing php-cache or Symfony tagged pool or decorating an Illuminate cache store. Be aware that tag-to-key indexing, write and delete consistency, and eviction behavior become your responsibility.
- Is cache/tag-interop production-ready and actively maintained?
- It is an interfaces-only package with a very small blast radius, hosted in a read-only repository and maintained through the php-cache organization. Signals are thin: roughly 105 stars, zero reported dependents, no SLA, no deprecation policy, and issues redirected to the main php-cache tracker. Keep the third-party namespace behind an application-owned port if you adopt it.
- What is the difference between cache/tag-interop v1 and v2?
- Version 2 extends psr/cache 3 and requires PHP 8+, version 1.1.0 bridged psr/cache v2, and version 1.0.x relied on PHPDoc return types. Modern projects should generally use ^2.0 unless constrained by an older PSR-6 stack. Confirm that your chosen adapter supports the same psr/cache major version.
- What are alternatives to cache/tag-interop for tag-based cache invalidation?
- In Laravel, use Cache::tags() with Redis, Memcached, or array stores where supported. Outside Laravel, use php-cache or Symfony adapters that implement taggable PSR-6 pools. Another option is an application-owned port with explicit key versioning or an index-based invalidation strategy. cache/tag-interop is an interop contract, not a tagging feature by itself.
- How should I test or migrate away from cache/tag-interop?
- Test through your own adapter or port rather than letting the third-party interface leak into application code, and cover tag writes, invalidations, deletes, and eviction behavior. Because the package is interfaces-only, exit is mechanical if you keep Cache\TagInterop out of business logic. Replacing it means swapping the adapter and port, not rewriting application code; migration cost grows only if you implement the interfaces directly on a custom store.