Console Architecture
The Console package follows a simple flow:
- define a command class by extending
CliCommand - let the console application construct the command
- let Symfony inject parsed input and output objects at runtime
- run the command's
exec()method
Command lifecycle
CliCommand uses protected properties to describe the command:
$name$description$help$args$options
When the command is constructed, the base class passes the name to Symfony and applies description and help text if they exist.
Later, Symfony calls configure(), and the base class translates $args and $options into real Symfony arguments and options.
When the user runs the command, execute() stores the current input and output objects and then calls exec().
Input model
Arguments and options are declared as arrays, not by overriding Symfony methods directly.
Supported argument modes are:
requiredoptionalarray
Supported option modes are:
nonerequiredoptionalarray
That keeps custom commands short, but it also means the declaration format must match what CliCommand expects.
Discovery model
CommandDiscovery::discover($directory, $namespace) scans the given directory, resolves class names, and returns metadata for each valid command.
A class is included only when all of these are true:
- the class exists
- the class is instantiable
- the class extends
CliCommand
For each matching class, discovery returns:
classnamedescriptionhelp
Because discovery instantiates the command just to read that metadata, constructors should stay lightweight and safe to run during command listing or bootstrap.
Built-in command pattern
The built-in commands are thin wrappers around other packages. For example:
cron:rundelegates to the Cron packagemigration:*delegates to the Migration packageroute:listbuilds routes through Module and Routercache:clearclears resource cache through Loader, Config, and Storage
That makes Console an orchestration layer rather than a separate application runtime.