murilochianfa/laravel-auto-optimizer
Automatically optimizes your Laravel application by caching config, routes, views, and clearing stale caches as needed. A lightweight package that keeps performance tuning hands-off so your app stays fast without manual artisan commands.
Start by confirming the package is actually compatible with your Laravel version before anything else — the v1.0.1 release is explicitly a "production ready" stamp, but it does not carry a changelog describing API changes, so treat the jump from v1.0.0 as probably stabilising but verify against the tagged diff:
composer require murilochianfa/laravel-auto-optimizer
composer show murilochianfa/laravel-auto-optimizer # note the exact tag + requirements
Where to look first, in this order:
vendor/murilo-chianfa/laravel-auto-optimizer/src/ — read the service provider(s) before you register anything. With a package named auto-optimizer, the interesting behaviour is when it triggers (boot? request? console? a scheduled job?), and that is only answerable from the provider's boot()/register() and any event listeners it hooks.php artisan vendor:publish --provider="MuriloChianfa\AutoOptimizer\..." (grab the exact FQCN from composer.json's extra.laravel.providers). Publish into config/ and commit it — do not rely on package defaults in production.README.md in the package root — the GitHub compare link in the release notes is the only other documentation signal you have, so read it there rather than trusting a summary.First use case: prove the trigger works in staging, not production. Install, leave defaults, deploy once, and then inspect what actually happened:
php artisan about # confirms provider discovered, config loaded
php artisan config:show <package-key> # confirm published defaults
tail -f storage/logs/laravel.log # see if the package logs its optimize calls
Then deliberately break something (edit .env, add a route) and see whether the package reacts. You are establishing the contract — does it re-cache on every request, on deploy, on a schedule, or only when you call a command?
Treat it as deploy-time, not request-time. The overwhelmingly common shape for this class of package is running optimize / optimize:clear automatically. The safe pattern is to let the package do its thing as the final step of a deploy, after composer install --no-dev and after your .env for that environment is in place:
composer install --no-dev --optimize-autoloader
php artisan migrate --force
# package's optimize step runs here (or you call it explicitly)
php artisan queue:restart
Gate it by environment. Whatever the config key is (enabled, environments, auto_optimize — check the published file), disable it in local and testing in config/auto-optimizer.php. Auto-caching config locally means every .env edit silently does nothing until you clear, which is a miserable developer experience and a common source of "why isn't my env var picked up".
// config/auto-optimizer.php — shape depends on the published file
'enabled' => env('AUTO_OPTIMIZER_ENABLED', app()->environment('production', 'staging')),
Pair it with your existing deploy tooling rather than duplicating it. If you already run php artisan optimize in Envoyer/Forge/Deployer, decide which one owns the job — two mechanisms racing to write bootstrap/cache/config.php is a real source of half-written cache files. Either remove your manual step or disable the package's, not both.
Always clear before you cache. Any workflow that re-optimizes should be optimize:clear && optimize, never optimize alone, especially across deploys where route files or config keys were renamed. If the package exposes both commands, wire the clear into your pre-deploy hook.
Assert behaviour in tests. If the package fires on an event or boot, use Artisan::fake() / Event::fake() in a feature test to pin the contract, so a future minor release can't silently start running config:cache in your test suite:
Event::fake([/* package event */]);
$this->get('/');
Event::assertDispatched(/* ... */);
Add observability. If the package logs, funnel it into your normal channel. If it doesn't, wrap your own call in a small artisan command you control and log the exit code — a failed route:cache (closure routes, duplicate names) will otherwise fail silently or blow up mid-deploy with an opaque error.
.env. Once bootstrap/cache/config.php exists, env() calls outside config files return null. If the package caches on boot and you subsequently edit .env, nothing changes. php artisan optimize:clear is the fix and should be muscle memory.route:cache refuses closures and duplicate route names. If enabling this package suddenly breaks your deploy, check for Route::get(..., function () {...}) and for two routes sharing a name before blaming the package.bootstrap/cache and storage/framework/views must be writable by the web user and the deploy user. Auto-optimizing packages commonly fail as the wrong user, producing Failed to write cache or permission errors on the compiled views directory.config:cache on a machine with a different .env than the target. Caching in CI and shipping the resulting artefact is a classic way to leak staging credentials into a production build. Cache on the server, after env is in place."murilochianfa/laravel-auto-optimizer": "^1.0.1" and move on.register()-time binding, and any dispatched events or command classes. Most "I need to change this" cases are solved by config + an event listener; only reach for a fork if the trigger condition itself is hardcoded.php artisan about (provider discovered?) → config published? → enabled flag true for this env? → is it console-only and you're testing over HTTP? → is it request-scoped and you're testing via CLI? The trigger surface is the number one confusion with packages of this name.How can I help you explore Laravel packages today?