Optimize & Cache Commands

## Why Laravel caches its own bootstrap On every request a Laravel application **boots**: it reads every file in `config/`, loads the route files and registers each route, discovers which listener classes handle which events, and compiles any Blade template it renders for the first time. In development that is what you want, because each edit shows up on the next request. In production nothing changes between deploys, so the work is repeated for no benefit. Laravel's answer is a set of Artisan commands that do the work once and write the result to a PHP file the framework can `require` directly. `php artisan optimize` is the single command that runs them all. Its source (`Illuminate\Foundation\Console\OptimizeCommand`) holds a small task list and runs each entry with `callSilently()`. ## What `optimize` runs | Key | Command | What it writes | What it replaces at runtime | |---|---|---|---| | `config` | `config:cache` | `bootstrap/cache/config.php` | loading every `config/*.php` file, and loading `.env` | | `events` | `event:cache` | `bootstrap/cache/events.php` | scanning listener directories for `handle` methods | | `routes` | `route:cache` | `bootstrap/cache/routes-v7.php` | executing `routes/web.php` and the other route files | | `views` | `view:cache` | compiled files in `storage/framework/views` | compiling a Blade template on its first render | After those four, `optimize` runs anything in `ServiceProvider::$optimizeCommands`: packages add entries there by calling `$this->optimizes(optimize: ..., clear: ...)` in their service provider. A few details worth knowing: - Each `:cache` command first calls its own `:clear`, so re-running `optimize` always rebuilds from the current code rather than layering on an old file. - `config:cache` boots a fresh copy of the application to collect configuration, writes it with `var_export`, and fails with a `LogicException` ("Your configuration files are not serializable") if a config value is something like a closure. - The cache file locations can be moved with environment variables such as `APP_CONFIG_CACHE`, `APP_ROUTES_CACHE` and `APP_EVENTS_CACHE`, which matters on read-only filesystems. ## What `optimize:clear` removes `php artisan optimize:clear` (`OptimizeClearCommand`) is not a pure mirror image. Its task list is: 1. `config:clear` 2. `cache:clear` — **flushes the default application cache store** 3. `clear-compiled` — deletes `bootstrap/cache/services.php` and `bootstrap/cache/packages.php` 4. `event:clear` 5. `route:clear` 6. `view:clear` 7. anything packages registered as their `clear` command The docs say it plainly: it removes the files `optimize` generated "as well as all keys in the default cache driver". On a production box that means cached query results, rate-limiter counters and anything else in the default store are gone too. `optimize:clear` is a development and troubleshooting tool; a deploy normally runs `optimize` alone, because each `:cache` step already clears its own old file. ## Skipping a step Both commands accept `--except` (short `-e`) with a comma-separated list. Each entry is matched against the task **key** or the **command name**, so these are equivalent: ```bash php artisan optimize --except=views php artisan optimize --except=view:cache php artisan optimize:clear --except=cache ``` The last line is the common one in practice: it clears the framework's bootstrap caches without wiping the application cache store. ## Where it belongs - **Production:** run `optimize` on every deploy, after the new code and its dependencies are in place. - **Local development:** do not leave caches in place. A cached route table or config file silently hides every edit you make until you clear it. - **Views are the forgiving one:** Blade compares the template's modification time with the compiled file's (unless `view.check_cache_timestamps` is set to false), so an edited view still recompiles. Config, route and event caches do no such check; they are used for as long as the file exists. ## Mistakes interviewers listen for - **Treating `optimize` as PHP tuning.** It builds Laravel's own bootstrap caches; it does not touch OPcache or Composer's autoloader, which are separate steps. - **Treating `view:cache` as required for correctness.** Without it, each template compiles on its first render; the command only moves that work to deploy time. - **Running `optimize:clear` on every deploy.** It is unnecessary and flushes the default cache store. - **Leaving caches on a laptop.** Edits to routes, config or listeners then appear to do nothing until someone clears them. - **Assuming the caches refresh themselves.** Only Blade checks timestamps; the other three are used for as long as their file exists. ## Summary - `optimize` = `config:cache` + `event:cache` + `route:cache` + `view:cache` + package-registered commands. - `optimize:clear` = the four `:clear` commands + `cache:clear` + `clear-compiled` + package-registered clear commands. - `--except` takes keys (`config`, `events`, `routes`, `views`, `cache`, `compiled`) or command names. - Run it per deploy in production; keep development uncached.