Cache Kernel Pack Laravel Package

Getting Started

The name is the tell: -pack plus "recipe" means this is a Composer meta-package. composer require mrgoodbytes8667/cache-kernel-pack pulls in mrgoodbytes8667/cache-kernel (the actual implementation) and, in a Symfony Flex project, applies a recipe that scaffolds config and wires the kernel in.

For a Laravel developer, the key consequence is: Laravel does not run Flex recipes. Installing the pack gives you the dependency but not the auto-configuration. Before writing any code:

1. Read vendor/mrgoodbytes8667/cache-kernel/README.md and its src/ — that's where the real API lives. The pack itself is usually just a composer.json with a require.
2. Check both packages' composer.json for extra.laravel.providers / aliases. If present, Laravel auto-discovery will register it and you're ahead; if absent, you'll register the service provider manually.
3. Look for a config/ directory in the underlying package to see what should land in config/cache-kernel.php.

The realistic first use case: fronting the app with an HTTP cache layer so anonymous GET responses are stored and replayed without invoking controllers — the classic "cache kernel" pattern. Smoke test:

composer require mrgoodbytes8667/cache-kernel-pack
php artisan vendor:publish --provider="Mrgoodbytes8667\\CacheKernel\\CacheKernelServiceProvider"
php artisan tinker   # resolve the kernel class to confirm it's bound

Confirm the binding actually exists before assuming the recipe-equivalent happened, because in Laravel it won't.

Implementation Patterns

Since auto-configuration is Flex-only, plan on wiring it yourself.

Kernel wrapping. The value here is a caching kernel class, not middleware. Bind it in a service provider:

$this->app->singleton(CacheKernel::class, function ($app) {
    return new CacheKernel(
        $app->make(\Illuminate\Contracts\Http\Kernel::class),
        $app->make('cache')->store(config('cache-kernel.store')),
    );
});

Then either rebind Illuminate\Contracts\Http\Kernel (applies to every request) or wrap it in a route middleware so only chosen routes are cached.

Route-scoped caching. Safer than global. Create a middleware that delegates to the cache kernel for whitelisted routes and leaves POST/PUT/DELETE untouched — the kernel should only short-circuit safe methods.

Store selection. Keep the store behind config. In practice the cache kernel wants something shared (Redis, Memcached, database). file in a multi-node deploy gives you silently inconsistent caches per host.

Invalidation on write. Standard pattern: listen to Model::saved / Model::deleted and purge the matching keys or tags. Design the key scheme (method + URI + query + Vary dimensions) up front; retrofitting tags later is painful.

Don't double-cache. If you already use spatie/laravel-responsecache or Cache::remember in controllers, don't run both. The HTTP cache kernel sits above controller-level caching; stacking them gives you two TTLs and two ways to serve stale data.

Gotchas and Tips

• Unmaintained risk. 0 stars, 0 dependents, a single 2024 release. Treat it as a reference implementation to read and adapt, not a dependency to adopt blindly. Run composer audit and read the kernel class before production.
• Flex recipe ≠ Laravel discovery. The "recipe" only runs under Symfony Flex. In Laravel, check extra.laravel in both packages; if it's absent, register the provider by hand and publish any config manually.
• Auth and cookie bleed. A naive HTTP cache will serve logged-in responses to anonymous users (or vice versa) if you don't respect Vary: Cookie/Authorization and mark authenticated responses Cache-Control: private. This is the most common way these kernels cause incidents.
• Stale on deploy. File-based stores survive deploys but can pin old Blade/PHP output. Add a deploy step that bumps a cache key prefix so a release intentionally invalidates everything.
• Vary handling is subtle. If query, headers, or locale affect the response, they must be in the cache key or the response's Vary header. Test with two Accept-Language values, not one.
• Debugging is opaque. When a response looks "too fast," check for Age/X-Cache headers before assuming a routing bug. Add a debug identifier header in dev only.
• Extension points. Look for a PSR-16 / Store abstraction, a purge interface, and a key generator — those are usually the seams for custom strategies. If the kernel hardcodes the Cache facade, wrap it rather than fork it.
• Skip non-cacheable endpoints. Don't let the kernel see Set-Cookie responses, health checks, or Laravel's built-in status/telescope routes.