Weave Code
In Memory Cache Laravel Package
beste/in-memory-cache
Lightweight PSR-6 in-memory cache for PHP. Ideal as a default cache implementation and for fast, dependency-free tests. Supports expirations and can use a PSR-20 clock (e.g. frozen clock) for deterministic time-based behavior.
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 use this package as a Laravel cache driver for local development?
- Register the driver in `config/cache.php` under the `'drivers'` array with `'in_memory'` as the key. Then extend the cache in `AppServiceProvider` using `Cache::extend()` with a new `Repository` wrapping the `InMemoryCache` class. This replaces the default array or file drivers for process-scoped caching.
- Can I use this package in Laravel tests to mock cache behavior?
- Yes, this package is designed for testing. Replace Laravel’s default cache pool with an `InMemoryCache` instance in your test setup. It supports PSR-6’s `getItem()`/`save()` methods, so it works with Laravel’s `Cache::shouldReceive()` assertions and `Cache::tags()` for testing tagged cache logic.
- Does this package support TTL (time-to-live) expiration for cached items?
- Absolutely. The package fully supports TTL via PSR-6’s `expiresAfter()` and `expiresAt()` methods. You can also inject a PSR-20 clock (like `beste/clock`) for deterministic time control in tests, ensuring consistent expiration behavior across test runs.
- Will this work with Laravel 10+ and PHP 8.3+ only? Can I use it in older Laravel versions?
- This package requires PHP 8.3+ and Laravel 10+ due to its dependencies. If you’re using an older Laravel version, consider alternatives like `symfony/cache` or `predis/predis` for in-memory caching, though they may not offer the same seamless Laravel integration.
- How do I handle memory leaks or unbounded cache growth in long-running Laravel processes?
- The cache is process-scoped, so it resets on process restart (e.g., after `artisan queue:work`). For testing, manually flush the cache using `Cache::flush()` or `Cache::forget()`. In production, avoid using this driver entirely—it’s designed for local/dev/testing only.
- Can I use this package in multi-process Laravel environments like queues or Horizon?
- No, this package is **not** thread-safe or distributed. Each process maintains its own in-memory cache, leading to inconsistencies. For queues or workers, use Redis or database drivers instead. Document this limitation clearly in your team’s environment guidelines.
- How does this package compare to Laravel’s built-in `array` cache driver?
- Unlike the `array` driver, this package is PSR-6 compliant, supports TTL, and integrates with Laravel’s `Cache` facade seamlessly. It also allows optional PSR-20 clock injection for testing, making it more flexible for complex caching logic like rate limiting or token expiration.
- Is there a way to enforce environment restrictions (e.g., block production use)?
- Yes, wrap the `InMemoryCache` in a custom Laravel driver that throws an exception in production. For example, add a check in your `AppServiceProvider` like `if (app()->environment('production')) throw new RuntimeException('In-memory cache disabled in production.')`.
- Does this package support Laravel’s cache tags (e.g., `Cache::tags(['user-123'])`)?
- Yes, it fully supports cache tags via PSR-6’s `getItem()`/`save()` methods. Laravel’s `Cache::tags()` will work as expected, though performance may vary compared to Redis or database-backed drivers for large-scale tagging.
- What are the performance implications of using this in-memory cache for large test suites?
- Performance is excellent for local/dev use, but memory usage grows linearly with cached items. For large test suites, monitor memory consumption and manually clear the cache between tests. Avoid storing large payloads (e.g., serialized models) unless necessary.
Weaver
How can I help you explore Laravel packages today?