Console — overview

Everything done around the project is done through one file — call. It starts the server, generates classes, applies the schema, manages background components and runs scripts of your own. One argument parser, one output format, one container.

Why a console

Development needs more than the request–response cycle: create a component, bring up the server, apply the schema, warm a cache, start a background handler, run a script once. Without a common tool that is a scatter of files in the project root, each with its own way of taking arguments and its own idea of how to print an error.

call gives one entry point: the same argument parsing, the same output, access to the container and to the application configuration — for the built-in commands and for yours alike.

How a call is structured

php call <command> [subcommand] [arguments] [-flags] [--options[=value]]

Parsing splits $argv into three parts:

The first argument is the command name; without one, help runs. Flags may be written separately or stuck together: -c -s -r and -csr are equivalent.

Short names

Four commands have aliases:

Running it from anywhere

The call file contains a chdir(__DIR__), so the commands work from any directory — just give the path:

php /srv/my-app/call mapping show

That is also what makes calls from systemd, cron and docker exec predictable: the working directory does not matter.

The commands

Development

Environment and data

Background components

Service

Help

php call                 # the same as help
php call help            # the command list + PHP, kernel and project versions
php call help make       # detailed help for one command
php call make -h         # the same thing, as a flag

call help with no arguments also prints the environment — the kernel version, the PHP version, the SAPI and the project root. That is the first thing worth attaching to a “why does this not work for me” question.

Shell completion

php call cfg completion       # print the script to stdout
php call cfg completion -i    # install it
php call cfg completion -if   # reinstall over the top

The shell is detected from $SHELL. For zsh the file goes to ~/.zsh/completions/_call and an fpath line is appended to ~/.zshrc; for bash, to ~/.bash_completion.d/call. Once installed, command names, subcommands and — where it makes sense — the project’s class names are completed.

A command of your own

A class extending Cmd. The scaffold is php call make -n .Sync:

use Flytachi\Winter\Console\Inc\Cmd;

class Sync extends Cmd
{
  public static string $title = 'sync external data';

  public function handle(): void
  {
      $from = $this->args['options']['from'] ?? 'yesterday';

      self::printInfo("syncing since {$from}");
      // ...
      self::printSuccess('done');
  }

  public static function help(): void
  {
      self::printInfo('call script main.command.Sync --from=2026-01-01');
  }
}

php call sc main.command.Sync --from=2026-01-01

The arguments arrive in $this->args — as those same three parts: arguments, flags, options.

Dependencies

The command is created by the container, so injection works as it does everywhere else:

class Sync extends Cmd
{
  #[Autowired] private ExchangeService $exchange;
  #[Autowired] private LoggerInterface $logger;

  public function handle(): void
  {
      $this->logger->info('sync started');
      $this->exchange->pull();
  }
}

Cmd or CmdCustom

Both are found by the scanner and both are run through call script. The only difference is how much boilerplate is mandatory — see script.

Output

There is no need to echo: Printer has ready-made shapes, and the whole console output looks alike:

An exception escaping handle() is caught and printed through printError() — the command does not crash into the console with a PHP stack trace.

Next

• make — generating components
• run — starting the application
• script — commands of your own
• Application components — what exactly run starts