Command's constructor executed on other commands call

[stebogit]

• Laravel Version: 9.x
• PHP Version: 8.1
• Database Driver & Version: Mysql 8

Description:

I created a couple of commands, that are suppose to be available only locally for development, both children of a common a parent class.

abstract class Dumper extends Command
{
    public function __construct()
    {
        parent::__construct();
        dump($this->connection_name);
    }

    public function handle()
    {
        if (!app()->environment('local')) {
           return $this->info('This command is only available for development.');
        }

        // ...
    }
}

class DumperA extends Dumper
{
    protected string $connection_name = 'A';
}

class DumperB extends Dumper
{
    protected string $connection_name = 'B';
}

While developing though I realized that every command class loaded in Laravel is instantiated every time any one of them is run.
In fact even running a completely unrelated command, like config:clear the constructor of both my new commands was executed (note the command does execute successfully anyway):

$ php artisan config:clear
"A" // app/Console/Commands/Dev/Dumper.php:30
"B" // app/Console/Commands/Dev/Dumper.php:30

   INFO  Configuration cache cleared successfully.  

I found this odd as I would expect each command to be completely independent from each other; in fact in the constructor of those dev commands I set some config variables that at this point I suppose would affect other commands.
Am I doing something wrong or missing something? Is using the constructor to set some common attributes not OK for some reason in this case?

This behavior also caused an issue once I pushed to staging, where the commands are also instantiated when the artisan package:discover command is executed (my command looks for a local file that on staging is not available):

Generating optimized autoload files
   > Illuminate\Foundation\ComposerScripts::postAutoloadDump
   > @php artisan package:discover

    [2023-03-17 17:38:29] stack.ERROR: Missing weather.cnf file {"exception":"[object] (Exception(code: 0): Missing weather.cnf file at /tmp/build_f49ece74/app/Console/Commands/Dev/Dumper.php:44)

Now, this might not be considered a bug, however I'd say it is a potentially dangerous unexpected side effect that would be worth clearly documenting, and I'd be happy to send a PR for that.
At the same time, is there maybe a different pattern or method to use to safely set class or instance attributes outside the constructor, or the only/best option is to do so inside the handle method?

[stebogit]

This seems to be an old/recurrent problem not only I struggled with:

• Running Artisan Command calls __construct methods of every command #32905
• All artisan command constructors are fired when running any artisan command #26570
• Any code within the __construct of a command will execute even when a different command is called #26427
• [5.1] All commands in app\Console\Commands\Kernel are instantiated when running unit tests #13789

Though the reason of this behavior does make sense, I'd say - regardless of what's considered appropriate to do in a constructor - it is not obvious that all commands are instantiated when any one is run, so it should be clearly documented (or fixed, but I guess that's much more complex).

[X-Coder264]

Laravel 9 added support for lazy commands -> #34873

Your command needs to have the AsCommand attribute with the name defined in order for that to work (or the static $defaultName property e.g. protected static $defaultName = 'command:name'; but that is not recommended as that approach has been deprecated in Symfony 6.1 and will be removed in Symfony 7 -> https://github.com/symfony/symfony/blob/v6.1.0/src/Symfony/Component/Console/Command/Command.php#L84).

So your example should look like this in order for the constructor to be called only when that specific command is being executed:

use Symfony\Component\Console\Attribute\AsCommand;

#[AsCommand(name: 'foo')]
class DumperA extends Dumper
{
    protected string $connection_name = 'A';
}

#[AsCommand(name: 'bar')]
class DumperB extends Dumper
{
    protected string $connection_name = 'B';
}

[driesvints]

Thanks @X-Coder264

[stebogit]

Thanks @X-Coder264 for the update, and I'm glad to see the issue is being addressed.
Though I'm not familiar with the syntax you used (i.e. #[AsCommand(name: 'foo')]), would you mind elaborating on what that does or maybe show another way of defining that attribute?
Would the protected $signature attribute still be relevant or the 'name' would replace it? Maybe you could point me to some docs on the (Symfony?) lazy commands I could read?
Also, I'm not clear why the lazy load is now not the default loading process, since it is also more efficient?

At any rate, all this seems still not documented anywhere in the docs - not even the lates one - and, especially if the default behavior remains the non-lazy load that still causes the present issue, I think it should be documented (will push a PR to the docs once I figure out the above details).

[X-Coder264]

@stebogit Laravel's documentation needs updating, in the meantime you can read about lazy commands and how they work in Symfony here -> https://symfony.com/doc/current/console/commands_as_services.html and https://symfony.com/doc/current/console/lazy_commands.html

As for examples you can check the commands that Laravel provides out of the box and how that attribute is used -> https://github.com/laravel/framework/search?q=AsCommand

Example of a Laravel command without any input arguments/options -> https://github.com/laravel/framework/blob/v10.4.1/src/Illuminate/Foundation/Console/RouteClearCommand.php

Example of a Laravel command with input arguments-> https://github.com/laravel/framework/blob/v10.4.1/src/Illuminate/Cache/Console/ForgetCommand.php