In Laravel, what do the `make:*` Artisan generators do, and what does `php artisan make:model Shipment -a` create?

## What a generator is Laravel's `make:*` commands are **code generators**. Each one takes a class name, picks a **stub** — a template file with placeholders such as `{{ namespace }}` and `{{ class }}` — replaces the placeholders, and writes the result to the directory where Laravel's conventions expect that kind of class. The Laravel 13 framework ships 37 of them (`php artisan list make` shows the set, plus any that packages add), covering models, controllers, middleware, jobs, events, listeners, mailables, notifications, policies, form requests, resources, casts, enums, tests and more. Generators exist for consistency and speed: every developer's controller or job starts from the same skeleton, in the same place, with the same namespace. ## Where files land and the rules they follow - The class goes under the application namespace that matches its type: models in `app/Models`, policies in `app/Policies`, jobs in `app/Jobs`, and so on. Folders that do not exist yet are created on demand, which is why a fresh Laravel 13 app has no `app/Jobs` until the first `make:job`. - A name with a slash, such as `make:controller Admin/ReportController`, produces a sub-namespace and sub-folder. - If you omit the name in an interactive terminal, the generator **prompts** for it; generators implement Laravel's prompt-for-missing-input behaviour. With `--no-interaction` a missing name is simply an error. - If the target class already exists, the command prints an error such as `Model already exists.` and leaves your file alone. `--force` overwrites it — rarely what you want on code that has been edited. - PHP-reserved words are rejected as class names. ## `make:model` and its companion flags `make:model` is the generator interviewers ask about most, because its flags scaffold a whole resource at once: | Flag | Creates for `Shipment` | |---|---| | `-m`, `--migration` | a `create_shipments_table` migration | | `-f`, `--factory` | `Database\Factories\ShipmentFactory` | | `-s`, `--seed` | `Database\Seeders\ShipmentSeeder` | | `-c`, `--controller` | `ShipmentController` | | `-r`, `--resource` | a resource controller type-hinting the model | | `-R`, `--requests` | `StoreShipmentRequest` and `UpdateShipmentRequest` used by the controller | | `--policy` | `ShipmentPolicy` bound to the model | | `-a`, `--all` | migration, factory, seeder, policy, resource controller and form requests | Short flags combine, so `php artisan make:model Shipment -mfsc` is a common everyday form. Running `make:model Shipment` interactively with no flags asks which of these companions you want. `-p` / `--pivot` generates a custom pivot model instead of a regular one. ## Tests and other shared flags Many generators accept `--test`, `--pest` or `--phpunit` to create a matching test class at the same time. Controllers take `--api` (no `create`/`edit` actions) and `--model=`; jobs, listeners and mailables have their own switches. `php artisan help make:<type>` is the quickest way to see them, because each help screen is generated from the command's signature. ## Choosing between `-a` and a smaller set `-a` is convenient in a tutorial and noisy in a real codebase. It produces a policy, a seeder and two form requests whether or not the feature needs them, and empty classes tend to survive in the repository long after anyone remembers why they exist. Many teams prefer to ask for exactly what the feature needs: - a read-only reference table might need only `-m` and `-f`; - an admin-managed resource typically wants `-mfsc` plus `--policy`; - an API resource might use `make:controller ShipmentController --api --model=Shipment --requests` after the model exists. Whatever you choose, read the generated files before committing: a factory with an empty `definition()` or a policy that returns nothing is a placeholder, not a decision. ## What generators do not do 1. They do not run anything: `-m` writes a migration file but does not migrate. 2. They do not fill in logic: the policy has empty methods, the factory an empty definition, the controller empty actions. 3. They register nothing — and in Laravel 13 most generated classes need no registration, because policies, event listeners and commands in the conventional folders are discovered automatically. 4. They do not update classes generated earlier when you later change a stub. ## Why interviewers ask A candidate who reaches for `make:model -mfsc` knows the conventional layout and saves the team from hand-written boilerplate that drifts in style. A candidate who knows the stubs behind the generators — and that they can be customised — is ready to shape a team's conventions rather than just follow them.