Weave Code
In Memory Cache Laravel Package
beste/in-memory-cache
A PSR-6 in-memory cache for PHP that works as a sensible default implementation and in tests. It supports PSR-20 clocks, including frozen clocks, so you can test time-based expiry without a real cache server. Simple, fast, and dependency-free. Install with composer require beste/in-memory-cache.
A PSR-6 In-Memory cache that can be used as a fallback implementation and/or in tests.
Frequently asked questions about In Memory Cache
- How do I install beste/in-memory-cache in a Laravel application?
- Run composer require beste/in-memory-cache. There is no Laravel service provider or config file; instantiate Beste\Cache\InMemoryCache directly where a PSR-6 CacheItemPoolInterface is expected. The package has no transitive dependencies, so installation is a single Composer line. If you are on PHP 8.1 or 8.2, pin to 1.4.x because version 1.5.0 requires PHP 8.3 or newer.
- Can I use beste/in-memory-cache as a Laravel Cache::store() driver?
- Not out of the box. The package implements PSR-6 CacheItemPoolInterface, while Laravel's cache layer uses Illuminate\Contracts\Cache\Store, so there is no config line that makes Cache::store('in_memory') resolve this pool. You would need to write and maintain an adapter mapping get, put, forget, and flush onto the PSR-6 pool. For Laravel-native code, the built-in array store already provides an in-memory, per-request, TTL-aware cache.
- What PHP and Laravel versions does beste/in-memory-cache support?
- The package is framework-agnostic and does not declare a Laravel dependency, so it can be used in Laravel 10, 11, or later as long as PHP is compatible. Version 1.5.0 requires PHP 8.3 or newer; Laravel 10 apps on PHP 8.1 or 8.2 must pin 1.4.x. Verify with composer why-not beste/in-memory-cache 1.5 before upgrading. Check the repository for the current support matrix.
- How do I test cache expiry without waiting in real time?
- Inject a PSR-20 clock into InMemoryCache, such as Beste\Clock\FrozenClock, and advance it in your test. Set an expiry with expiresAfter(new DateInterval('PT5M')), save the item, then move the frozen clock forward with setTo and assert isHit(). This gives deterministic TTL tests without a real cache server, sleeping, or Carbon::setTestNow() against a live store. The README includes a working frozen-clock example.
- Can beste/in-memory-cache replace Redis as a production fallback?
- Not in a typical PHP-FPM application. The pool is created and destroyed per request, so it cannot absorb a Redis outage because nothing survives to the next request. In long-lived processes such as Octane or queue workers it persists, but it has no LRU, max-size, or memory cap, so unbounded growth becomes a leak risk. Use Laravel's array store for request-scoped caching, or a real shared cache for resilience.
- Is beste/in-memory-cache better than Laravel's array cache store?
- They solve different interface problems. Laravel's array store implements the framework's Store contract and is the natural choice for Laravel-native code, including Cache::store('array'). Beste's package implements PSR-6, so it is valuable when a third-party library type-hints CacheItemPoolInterface. The other differentiator is its injectable PSR-20 clock for deterministic expiry testing.
- How do I use it with a library that requires a PSR-6 cache pool?
- Instantiate InMemoryCache and pass it to the constructor or setter that accepts Psr\Cache\CacheItemPoolInterface. There is no Laravel wiring or glue code needed because the library and the package share the PSR-6 contract. This is the strongest fit for the package: test seams and Symfony-derived or Geocoder-style dependencies pulled in transitively.
- Does beste/in-memory-cache support TTL and expiration?
- Yes. It is a PSR-6 pool, so items support expiresAfter() with a DateInterval and expiresAt() where applicable. Expiry is evaluated against an injected PSR-20 clock, defaulting to the system clock. That makes it straightforward to test time-based expiration deterministically.
- Is beste/in-memory-cache safe to use in Laravel Octane or queue workers?
- It can persist across requests or jobs in long-lived processes, but that is not automatically safe. The cache has no eviction policy or memory cap, so a growing key space becomes a leak unless every write has a TTL and keys are bounded. It is also not cross-process consistent, so two workers see different caches and read-your-writes assumptions can break. Prefer a shared cache for correctness-critical data.
- Is beste/in-memory-cache actively maintained and what are the alternatives?
- It is a small MIT-licensed package with a single maintainer and modest adoption, so treat forkability as the main insurance policy rather than release cadence. Verify the release metadata before citing active maintenance in a decision record. Alternatives include Laravel's array store for framework-native tests, symfony/cache ArrayAdapter for PSR-6, or a small custom fake. For PSR-6 plus a frozen clock, this package is a readable drop-in.
Weaver
How can I help you explore Laravel packages today?