Laravel Cache Laravel Package

Getting Started

1. Install and confirm discovery. composer require dragon-code/laravel-cache — the package is Laravel-only and registers via package discovery, so there is normally no config/app.php edit. Before writing code, open composer.json in the vendor folder and check the require block: this is a small package (≈70 stars) and the supported Laravel/PHP range is the single fastest way to know whether it fits your app's version. As of 4.2.0 the range extends through Laravel 13, so apps still on 10/11/12 are supported too — confirm the exact floor in composer.json, because Laravel 13 support was added in a minor (4.2.0), not a major, which tells you the author treats framework compat as non-breaking.
2. Read the source before the README. With a small helper package the README is usually a summary and the real contract lives in vendor/dragon-code/laravel-cache/src/. Spend ten minutes skimming the classes and, more importantly, the tests/ directory — the test suite is the de facto documentation and shows the exact call signatures, default TTLs, and key formats the author intended. Note that 4.2.0 rebranded the README around the name "Smart Cache"; the Composer package name did not change, so search the vendor tree under dragon-code/laravel-cache and expect docs/classes to use the Smart Cache vocabulary. Trust src/, not the branding.
3. First use case: consolidate scattered Cache:: calls. The realistic day-one win is not a new feature but a refactor. Find places where your app calls Cache::remember(), Cache::put(), and Cache::forget() with hand-built string keys, and route them through the package helper so key construction, TTL defaults, and flushing live in one place.
4. Drop it behind a thin seam. Create app/Support/Cache/CacheService.php (or similar) that calls the package, and inject that into your controllers/jobs. At 70 stars and 0 known dependents, you want a one-file swap if the package stalls.

Implementation Patterns

Wrap the helper, don't sprinkle it. The package's value is consistency. Keep every call site going through one or two of your own classes so the key format and TTL policy are enforced centrally:

final class CacheService
{
    public function rememberUser(int $id, Closure $resolver): User
    {
        return cache()->remember(
            $this->key("users.{$id}"),
            now()->addMinutes(30),
            $resolver
        );
    }

    private function key(string $suffix): string
    {
        return sprintf('app:%s:%s', config('app.env'), $suffix);
    }
}

Version your keys. Because invalidation in this style of package is usually key-based rather than tag-based, embed a version segment (app:v3:users.42) and bump it on schema or serialization changes. That gives you a coarse "flush everything" button that works on every driver, including file and database, where tags are unavailable.

Invalidate from model events, not controllers. If the package ships model-caching conveniences, wire invalidation into booted() observers so a saved/deleted anywhere in the app clears the right entries. Controllers get bypassed by console commands and queues; model events do not.

protected static function booted(): void
{
    static::saved(fn (self $m) => app(CacheService::class)->forgetUser($m->id));
    static::deleted(fn (self $m) => app(CacheService::class)->forgetUser($m->id));
}

Cache the payload, not the Eloquent model. Serializing full models across deploys is where stale-cache bugs come from — a column rename produces a fatal unserialize on live traffic. Cache arrays/Data objects or DTOs and rehydrate at the edge.

Test with the array driver. In phpunit.xml set CACHE_STORE=array, and call Cache::flush() in setUp() (or use RefreshDatabase-style traits) so cached state never leaks between tests. For assertions about whether you cached, prefer Cache::spy() / Cache::shouldReceive('put') over reading the store back — it catches accidental double-caching.

Treat it as a seam for queue-heavy code. In jobs, wrap expensive aggregate queries in the helper with a short TTL and jittered expiry (now()->addMinutes(30)->addSeconds(rand(0, 60))) to avoid a thundering herd when a batch of workers starts at once.

Upgrading to 4.2.0 is a no-op. The release adds Laravel 13 support plus README/banner/LICENSE housekeeping — no API, config, or key-format changes. Bump the constraint, run your cache test suite, ship. If you're on Laravel 13 and previously pinned below 4.2, this is the release that unblocks you; treat it as an enabler, not a migration.

Gotchas and Tips

• Tags require the right driver. If you plan to use cache tags, verify the configured store supports them — file and database throw BadMethodCallException on tags(). A package helper that looks tag-based in the README may silently be key-based; confirm in src/ before designing around it.
• TTL semantics differ between null and 0. In Laravel's cache contract, null means "forever" and 0/negative means "immediately expired". If the package applies its own default TTL when you pass null, that's a behavior change worth pinning down with a test.
• Key constraints bite at scale. Memcached caps keys at 250 bytes and disallows whitespace; Redis dislikes very long keys and colons are convention, not a namespace. If your helper interpolates raw user input into keys, hash it — and never let an unvalidated email address become part of a key.
• Deploy-time invalidation. New release, new serialization format: stale entries cause unserialize() errors that only appear in production. Either bump the key prefix per deploy (app:v{release}:) or run an explicit flush as a deploy step. Do not rely on the package to handle this. 4.2.0 itself changes nothing serialized, but the next major might.
• Debugging misses. When something isn't caching, log Cache::getStore() and the resolved store name first — a misconfigured CACHE_STORE (or a .env that differs between web and queue workers) accounts for most "the cache doesn't work" reports. Telescope's cache panel and Cache::getDefaultDriver() resolve the rest quickly. On a fresh Laravel 13 install, check the new default store name in config/cache.php before assuming the package is at fault.
• Config quirks. If the package publishes a config file (php artisan vendor:publish --tag=...), publish it rather than relying on undocumented defaults, and commit it — otherwise a future minor release can change behavior under you without a diff.
• Branding vs. package identity. 4.2.0 leans into "Smart Cache" in the docs. Your composer.json, the vendor path, and issue searches still use dragon-code/laravel-cache; don't rename your imports or search the wrong namespace when chasing docs or Stack Overflow answers. If a future release renames the Composer package, that will be a breaking change worth a dedicated PR.
• Pin the version. A minor release adding Laravel 13 support is a good sign of maintenance, but a helper package with a small user base gets refactored without much deprecation ceremony. Use a caret constraint on a tested minor (^4.2) and read the changelog on bumps — you want 4.2+ for Laravel 13, and you don't want to be surprised by 5.0.
• Extension points to prefer. If it exposes a facade, Laravel macros (CacheHelper::macro(...)) let you add domain helpers without forking. If it exposes a trait, prefer composing it in your own base class over applying it to dozens of models — one place to swap later.
• Have an exit plan. Keep the wrapping service thin enough that replacing the package with plain Cache:: calls is a half-day task. That's the real insurance policy for a 70-star dependency.