In Laravel 13, why does config('view.paths') return a value when config/view.php does not exist, and how do you change it?

## Two config directories, one repository A Laravel 13 app has two sources of configuration files: - **`config/` in the application.** The laravel/laravel skeleton ships ten files: `app`, `auth`, `cache`, `database`, `filesystems`, `logging`, `mail`, `queue`, `services` and `session`. - **`config/` inside `laravel/framework`.** It holds a complete set, including files the skeleton leaves out: `broadcasting`, `concurrency`, `cors`, `hashing`, `images` and `view`. This split started with Laravel 11's slim skeleton. Before that, a new app received every config file, most of which nobody edited. ## How the files are merged When configuration is loaded (and there is no config cache), the bootstrapper does roughly this: 1. Load every framework config file into a **base** array, keyed by file name. 2. For a framework file with **no** app counterpart, put the framework array into the repository unchanged. That is why `config('view.paths')` returns `[resource_path('views')]` with no `config/view.php`. 3. For an app file that **does** have a framework counterpart, `array_merge` the app array over the base. Your top-level keys win; keys you omit keep the framework's value. 4. For a few nested options the merge goes one level deeper, so the framework's named entries survive next to yours: | File | Options merged one level deeper | |---|---| | `auth` | `guards`, `providers`, `passwords` | | `broadcasting` | `connections` | | `cache` | `stores` | | `database` | `connections` | | `filesystems` | `disks` | | `logging` | `channels` | | `mail` | `mailers` | | `queue` | `connections` | So deleting the `pgsql` entry from your `config/database.php` does not remove the connection: the framework's `pgsql` connection is merged back in. Defining your own entry with the same name replaces the framework's entry as a whole. An application can opt out with `dontMergeFrameworkConfiguration()` on the application instance, in which case only its own files are loaded. ## Change it without publishing, when you can Many framework config values already read an environment variable. The framework's `view.php` has two keys: - `paths`: a plain array, `[resource_path('views')]`, with no `env()` call. - `compiled`: `env('VIEW_COMPILED_PATH', realpath(storage_path('framework/views')))`. To move compiled templates, set `VIEW_COMPILED_PATH` and publish nothing. To add a second view directory, there is no variable, so you publish the file. ## Publishing a file with `config:publish` ```bash php artisan config:publish view # copy one file php artisan config:publish # choose from a list php artisan config:publish --all # copy every framework file php artisan config:publish view --force # overwrite an existing copy ``` - The command copies the framework's file into `config/` so you can edit it. - An unknown name prints "Unrecognized configuration file." and the command fails. - If the file already exists it refuses unless you pass `--force`. Publish only the files you change. A published file is a snapshot: later framework releases may add keys to their copy, and your copy will not show them (the merge still supplies top-level keys you omit, but readers of your file will not see them). ## Inspecting what resolved with `config:show` `php artisan config:show view` prints the resolved values of a file in dot notation, after the merge and after `env()` calls. It also takes a single key, such as `config:show view.paths`. If the file or key does not exist in the repository, the command fails with a "does not exist" message. ## A gym-membership example The gym app keeps branch-specific email and page templates in `resources/branch-views` and wants Blade to find them: 1. Run `php artisan config:publish view`. 2. Add `resource_path('branch-views')` to `paths` in the new `config/view.php`. 3. Run `php artisan config:show view.paths` to confirm the two directories. ## Why the design changed Before the slim skeleton, every app carried dozens of config files it never touched, and each upgrade guide asked teams to diff them against the new release. Moving the defaults into the framework means an untouched setting follows the framework automatically, and the `config/` directory of an app shows only what that team chose to change. The cost is discoverability: a developer who looks for a setting in `config/` and does not find it has to know that `config:show` or the framework's own file is the place to look. ## Points interviewers probe - A missing config file is not a missing setting; the framework supplies it. - Check for an existing environment variable before publishing a file. - Publishing is a copy, not a link. - The merge is shallow except for the named options above. - `config:show` answers "what value is the app really using?" faster than reading files.