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.

In either case, if your class extends Symfony\Bundle\FrameworkBundle\Command\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
{
    protected static $defaultName = 'app:sunshine';
    private $logger;

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

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

    protected function configure()
    {
        $this
            ->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.

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

    // ...
}