In Laravel, how do `php artisan list`, `php artisan help` and `php artisan about` help you get oriented in an unfamiliar application?
answer
- three read-only commands, three scopes
- inventory grouped by namespace
- list make narrows to one namespace
- help: arguments, options, global flags
- about --only=environment, --json
basics
~10 sphp artisan list prints every registered command grouped by namespace, php artisan help <command> shows one command's arguments and options, and php artisan about summarises versions, environment, debug mode, cache status and drivers.
solid answer
~40 s`php artisan list` prints every command the application has registered — the framework's, installed packages' and the team's own — grouped by namespace, and `php artisan list make` narrows it to one namespace. `php artisan help migrate` (or `php artisan migrate --help`) prints one command's description, usage, arguments and options, generated from its signature, plus the global options such as `--env`. `php artisan about` is the snapshot: Laravel, PHP and Composer versions, environment, debug and maintenance mode, whether config, events, routes and views are cached, and which cache, database, queue, session, mail and log drivers are configured. `--only=environment,drivers` filters the sections and `--json` exports them. On an unfamiliar app I run `about` first, then `list` to find the team's custom commands, then `help` on anything before I run it.
go deeper
Recall the three commands and what each prints: list for the inventory, help for one command's arguments and options, about for versions, environment, cache status and drivers.
Explain that help is generated from the command's signature, that list groups by namespace and skips hidden commands, and what about's Environment, Cache, Drivers and Storage sections mean.
Show an inspection routine: about --json on each server to compare drivers and cache state, list to find a legacy team's own commands, help before running anything that writes.
Treat list and about as cheap onboarding and audit tools, and argue for commands with real descriptions so the Artisan listing stays a trustworthy map of team tooling.
## What Artisan is **Artisan** is the command-line interface every Laravel application carries as the `artisan` script in its root directory. Running `php artisan <command>` boots the real application — the same `bootstrap/app.php`, service providers and configuration a web request uses — registers every console command that the framework, the installed packages and the application define, and then runs the one you named. Because it boots *this* application, the answers Artisan gives describe this codebase and its configuration, not the framework's defaults. That makes three read-only commands the natural first stop when you open a project you did not write: `list`, `help` and `about`. ## `php artisan list`: the command inventory `php artisan list` (running `php artisan` with no command does the same) prints every registered command with its one-line description, grouped by **namespace** — the part of the name before the colon: - Framework namespaces such as `make`, `migrate`, `db`, `model`, `queue`, `route`, `schedule`, `config` and `cache`. - Commands registered by packages, for example the `sail:*` commands once Sail is installed. - The application's own commands: classes in `app/Console/Commands`, which Laravel registers automatically, and closure commands defined with `Artisan::command()` in `routes/console.php`. - `php artisan list make` narrows the output to a single namespace; in Laravel 13 the framework alone contributes 37 `make:*` generators, and packages can add more. One caveat: a command can be marked **hidden** — the `$hidden` property or the `#[Hidden]` attribute — and then it is left out of the listing while still running when called by name. `list` is an inventory of *advertised* commands, not proof that nothing else exists. ## `php artisan help <command>`: one command's contract `php artisan help migrate`, or equivalently `php artisan migrate --help`, prints the command's description, a usage line, and every argument and option with its description and default. The text is generated from the command's **signature**, so it cannot drift from the code the way a wiki page can. The same screen lists the **global options** every command accepts, including: - `--env`, which sets the environment the command runs under; - `-n` / `--no-interaction`, which suppresses questions; - `-q` / `--quiet` and the `-v` / `-vv` / `-vvv` verbosity levels. Reading `help` before running an unfamiliar custom command is cheap insurance: a legacy `orders:fix` might take a `--commit` switch you really want to know about first. ## `php artisan about`: the application snapshot `about` gathers facts from the booted application and prints them in sections: | Section | What it reports | |---|---| | Environment | application name, Laravel, PHP and Composer versions, environment name, debug mode, URL, maintenance mode, timezone, locale | | Cache | whether config, events, routes and views are `CACHED` or `NOT CACHED` | | Drivers | the configured broadcasting, cache, database, log, mail, queue and session drivers, plus Octane and Scout when set | | Storage | whether each configured public storage link exists (`LINKED` / `NOT LINKED`) | - `--only=environment,drivers` limits output to the named sections (comma-separated). - `--json` prints the same data as JSON — useful for pasting into a ticket or diffing two servers. - Packages can append a section with `AboutCommand::add('Billing', fn () => [...])`, usually from a service provider's `boot()` method. Note what the Cache section means: it says whether the *framework's* configuration, route, event and view caches are built, not what your cache store holds. ## A day-one routine for an unfamiliar app 1. `php artisan about` — which Laravel and PHP versions, which environment, whether debug is on, which drivers the team chose. 2. `php artisan list` — scan for namespaces that are not the framework's: those are the team's own scripts and the best map of what they automate. 3. `php artisan help <command>` on each unfamiliar custom command before running it. 4. Only then move on to schema and model inspection with the database commands. ## Caveats worth knowing - All three commands report what the **CLI process** resolves. If the web server supplies different environment variables, the web application can behave differently from what `about` printed. - `NOT CACHED` in the Cache section on a production server is a finding worth raising with whoever owns deployment. - None of the three changes anything: they are safe on any server, which is exactly why they come first.
- How can a package add its own lines to `php artisan about`?It calls `AboutCommand::add()`, usually in its service provider's `boot()` method, with a section name and either an array or a closure returning key/value pairs — for example `AboutCommand::add('Billing', fn () => ['Gateway' => config('billing.gateway')])`. The closure runs when `about` runs, so the values are current, and the new section can be selected with `--only`.
- Why might a custom command exist and run, yet not appear in `php artisan list`?It is probably marked hidden — `protected $hidden = true` or the `#[Hidden]` attribute. Hidden commands are left out of the listing but still execute when called by name, which teams use for internal or one-off tooling. So `list` shows advertised commands; searching `app/Console/Commands` and `routes/console.php` is how you find the rest.
saying these in an interview costs you the question
- php artisan list shows only framework commands, never the app's or packages' commands.
- A command missing from php artisan list cannot exist or be run.
- php artisan about clears caches or otherwise changes the application.
- The Cache section of about shows what the cache store currently holds.
- You must read a command's source code to learn its arguments and options.