How to Define Commands as Services

3.4 version

Maintained

Unmaintained

2.7 2.8 3.0 3.1 3.2 3.3 4.0 4.1

edit this page

How to Define Commands as Services
- Lazy Loading

How to Define Commands as Services¶

If you're using the default services.yml configuration, your command classes are already registered as services. Great! This is the recommended setup.

Symfony also looks in the Command/ directory of each bundle for commands non registered as a service and automatically registers those classes as commands. However this auto-registration was deprecated in Symfony 3.4. In Symfony 4.0, commands won't be auto-registered anymore.

Note

You can also manually register your command as a service by configuring the service and tagging it with console.command.

In either case, if your class extends ContainerAwareCommand, you can access public services via $this->getContainer()->get('SERVICE_ID').

But if your class is registered as a service, you can instead access services by using normal dependency injection.

For example, suppose you want to log something from within your command:

namespace AppBundle\Command;

use Psr\Log\LoggerInterface;
use Symfony\Component\Console\Command\Command;
use Symfony\Component\Console\Input\InputInterface;
use Symfony\Component\Console\Output\OutputInterface;

class SunshineCommand extends Command
{
    private $logger;

    public function __construct(LoggerInterface $logger)
    {
        $this->logger = $logger;

        // you *must* call the parent constructor
        parent::__construct();
    }

    protected function configure()
    {
        $this
            ->setName('app:sunshine')
            ->setDescription('Good morning!');
    }

    protected function execute(InputInterface $input, OutputInterface $output)
    {
        $this->logger->info('Waking up the sun');
        // ...
    }
}

If you're using the default services.yml configuration, the command class will automatically be registered as a service and passed the $logger argument (thanks to autowiring). In other words, just by creating this class, everything works! You can call the app:sunshine command and start logging.

Caution

You do have access to services in configure(). However, if your command is not lazy, try to avoid doing any work (e.g. making database queries), as that code will be run, even if you're using the console to execute a different command.

Lazy Loading¶

New in version 3.4: Support for command lazy loading was introduced in Symfony 3.4.

To make your command lazily loaded, either define its $defaultName static property:

class SunshineCommand extends Command
{
    protected static $defaultName = 'app:sunshine';

    // ...
}

Or set the command attribute on the console.command tag in your service definition:

YAML

services:

    AppBundle\Command\SunshineCommand:
        tags:
            - { name: 'console.command', command: 'app:sunshine' }
        # ...

XML

<?xml version="1.0" encoding="UTF-8" ?>
<container xmlns="http://symfony.com/schema/dic/services"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://symfony.com/schema/dic/services https://symfony.com/schema/dic/services/services-1.0.xsd">

    <services>

        <service id="AppBundle\Command\SunshineCommand">
            <tag name="console.command" command="app:sunshine"/>
        </service>

    </services>
</container>

PHP

use AppBundle\Command\SunshineCommand;

// ...

$container
    ->register(SunshineCommand::class)
    ->addTag('console.command', ['command' => 'app:sunshine'])
;

Note

If the command defines aliases (using the getAliases() method) you must add one console.command tag per alias.

That's it. One way or another, the SunshineCommand will be instantiated only when the app:sunshine command is actually called.

Note

You don't need to call setName() for configuring the command when it is lazy.

Caution

Calling the list command will instantiate all commands, including lazy commands.

This work, including the code samples, is licensed under a Creative Commons BY-SA 3.0 license.