mrgoodbytes8667/kernel-pack
Kernel Pack bundles kernel-level customizations for Laravel into one package, making it easier to organize and register HTTP and console kernel behavior without scattering related configuration across multiple service providers. Lightweight and easy to add to existing apps.
What it actually is. mrgoodbytes8667/kernel-pack is a Composer pack, not a library. It ships no runtime code; its payload is (a) a composer.json that pulls in a curated set of Symfony packages and (b) a Symfony Flex recipe that writes files into your project — here, a kernel whose cache and log directories point somewhere other than the default var/cache and var/log. Treat it as scaffolding you install once, not as a dependency you keep in the loop.
This is a Symfony package. As a Laravel developer, the honest first step is to confirm this belongs in the project at all. If you're in a Laravel app, stop — Laravel has no kernel class to patch and no Flex recipe pipeline; the analogue is $app->useStoragePath() plus a log-path override in bootstrap/app.php. This pack is only relevant if you're working in a Symfony codebase (or evaluating one) that wants cache/log outside the project root.
Minimal steps for a Symfony project:
composer require symfony/flex. Without it, recipes never run and you get only the dependency list.composer show mrgoodbytes8667/kernel-pack --all and read the require block in the pack's composer.json.composer require mrgoodbytes8667/kernel-pack. Answer the Flex prompt and immediately git diff — the recipe's changes are the thing you're actually adopting.composer recipes mrgoodbytes8667/kernel-pack.Where to look first. The applied diff, specifically the kernel's cache/log directory logic — read what path it resolves to and where that value comes from (env var, hardcoded path, or a %kernel.project_dir% relative value). Then run bin/console about and bin/console debug:container --parameter=kernel.cache_dir to see the effective values under your real environment.
First use case. A container or immutable deploy where the release directory (or /) is read-only and only a mounted volume is writable, so var/cache and var/log must move to /tmp, a shared volume, or a per-release directory. Second use case: several Symfony apps on one host that need segregated cache/log roots without duplicating kernel boilerplate.
Fresh project vs. existing project. In a fresh skeleton the recipe applies cleanly and you inherit a working kernel. In an existing app with src/Kernel.php already present, Flex will not silently overwrite — it prompts or skips, and you can end up with the pack installed but the intended behaviour absent. Verify with composer recipes every time; don't assume.
Recipe as a one-shot scaffold. Apply it, commit the diff, then treat src/Kernel.php as your file. From that point the pack adds nothing day-to-day — it's a transitive require you carry. If you want the dependency set without the recipe, composer recipes:uninstall or delete the pack after copying the kernel methods.
Env-driven paths. Whatever the recipe's kernel reads (check the applied code — it may be a specific env var name or a getenv() with a default), wire it through .env / .env.local / per-environment files rather than editing the kernel per host. Keep a sane fallback so a missing variable doesn't yield cache_dir = ''. The pattern to aim for:
public function getCacheDir(): string
{
return rtrim($_SERVER['APP_CACHE_DIR'] ?? '', '/') ?: $this->getProjectDir().'/var/cache/'.$this->environment;
}
Deploy pipeline. Set the cache directory per release (e.g. /var/cache/app/$RELEASE) so a rollback doesn't inherit a poisoned cache, and run bin/console cache:warmup during the build step against that path. Logs go to a shared, persistent directory, not a per-release one — otherwise rollbacks orphan your logs and log shippers lose the file.
Docker / PHP-FPM. Mount a volume for logs, put the cache on a writable layer or tmpfs, and make sure the FPM user (www-data, uid 33, or whatever your image uses) owns both paths. A cache dir created by root during composer install is the single most common cause of "works in build, 500s at runtime."
Multiple apps, one host. Share a parent root (/var/cache/) but namespace per app and per environment inside it. Sharing an actual cache directory across two apps produces confusing container-compilation errors, not obvious ones.
If you're porting the idea to Laravel. $app->useStoragePath($path) moves storage/ (and therefore storage/logs and storage/framework/cache) wholesale; useBootstrapPath() handles the compiled-services cache directory. Read the path from an env var in bootstrap/app.php, and remember config:cache/optimize:clear need the resulting directories to exist and be writable at deploy time.
require block may pin or pull Symfony versions that conflict with a modern app. Audit with composer why mrgoodbytes8667/kernel-pack and composer outdated --direct before and after requiring. For production, strongly prefer copying the kernel methods into your own Kernel and dropping the dependency — you get identical behaviour with no supply-chain risk and no version constraints.extra.symfony.endpoint. If you require the pack and composer recipes shows nothing, that's the cause — add the endpoint (from the pack's README) before requiring, and re-run. Also note that adding a third-party endpoint changes where Flex looks for all recipes.--force destroys customisations. composer recipes:install mrgoodbytes8667/kernel-pack --force and composer sync-recipes --force will happily overwrite a src/Kernel.php you've since edited. Commit or stash first, always.composer update does not re-run recipes. The tools are composer recipes:update (interactive diff review) and composer sync-recipes. Knowing this saves an hour of "why didn't the change apply."Failed to remove directory, Unable to create the cache directory, or a container-compilation error referencing a path you never wrote. Always confirm the resolved paths first with bin/console about and debug:container --parameter=kernel.cache_dir --parameter=kernel.log_dir.%kernel.cache_dir% follows automatically — that's the good news. The bad news is code or config that hardcodes %kernel.project_dir%/var/cache (or a Dockerfile chown of /app/var) will now point at a directory that no longer holds the cache. Grep for var/cache and var/log across config/, Dockerfiles, CI files, and nginx/php-fpm configs after applying..env, and empty strings count. A container that sets APP_CACHE_DIR="" will blank your path with no warning. Use ?? plus an emptiness check.var/log breaks logrotate configs, Monolog handlers with relative filenames, and filebeat/fluentd tails. Update them in the same change, and don't put logs on tmpfs unless you accept losing them on restart.getCacheDir()/getLogDir() in a kernel you own; (2) keep the pack for its dependency set only, with the recipe uninstalled; (3) depend on the pack as shipped — only acceptable if you've pinned the version and accepted that no one is maintaining it.php artisan config:cache, no config/ files to edit, and no service provider auto-discovery involved. The equivalent verification command is bin/console debug:container, and the equivalent of storage_path() is a method on a class you're now editing by hand.How can I help you explore Laravel packages today?