I like it a lot, it reminds me#49522
just a question, does this competes/supersedes#57225 ?
Cheers

cc@kbond as you are the author of

https://github.com/zenstruck/console-extra

cc@kbond as you are the author of
https://github.com/zenstruck/console-extra

We had a chat recently about this topic and that repo was my inspiration actually

I've tested theSymfony one-file demo with this approach for a single-app command, and this is the result:

<?phprequire_once__DIR__.'/vendor/autoload_runtime.php';useSymfony\Bundle\FrameworkBundle\Console\Application;useSymfony\Bundle\FrameworkBundle\Kernel\MicroKernelTrait;useSymfony\Component\Console\Attribute\Argument;useSymfony\Component\Console\Attribute\AsCommand;useSymfony\Component\Console\Style\SymfonyStyle;useSymfony\Component\HttpKernel\Kernel;#[AsCommand('app:start')]class SymfonyOneFileAppextends Kernel{use MicroKernelTrait;publicfunction__invoke(SymfonyStyle$io, #[Argument]string$name ='World'):void    {$io->success(sprintf('Hello %s!',$name));    }}returnstaticfunction (array$context) {returnnewApplication(newSymfonyOneFileApp($context['APP_ENV'], (bool)$context['APP_DEBUG']));};

It's missing having services autowired on the method, though.

I like it a lot, it reminds me#49522
just a question, does this competes/supersedes#57225 ?
Cheers

@94noni They are related yes. I'm waiting for a deeper conversation with@chalasr to get more insights about the work he is doing in this regard, but in theory this should close & replace those proposals.

I love it! Really nice DX addition 👏

I’ve concerns about supporting#[AsCommand] on public methods and allowing multiple commands on the same class/instance:

• when extending from theCommand class, methods likeisEnabled(),interact(), orinitialize() will respond to all commands defined in that class, which is undesirable
• when not extending from theCommand class, there is currently no way to inspect methods with the#[AsCommand] attribute unless we also repeat#[AsCommand] on the class itself (for autoconfiguration/tagging) not true, it's actually supported
• last but not least, it won’t align with the SRP

I don't think it's a good idea to support that

I’ve concerns about supporting#[AsCommand] on public methods and allowing multiple commands on the same class/instance:

• when extending from theCommand class, methods likeisEnabled(),interact(), orinitialize() will respond to all commands defined in that class, which is undesirable

Let's just say that these functions are rarely used in final projects, and that if you want to use them, it's worth separating the commands into separate classes.

• when not extending from theCommand class, there is currently no way to inspect methods with the#[AsCommand] attribute unless we also repeat#[AsCommand] on the class itself (for autoconfiguration/tagging)

To quote@stof:

TheregisterAttributeForAutoconfiguration method inspects the parameter type of the configuration callback to discover which source need to be inspected.

• last but not least, it won’t align with the SRP

SRP is an implementation principle that can be left up to the developer. I once had 2 commands that were functionally very close to each other, but with different arguments. To share part of the code between the 2, I needed an abstract class. With this new approach, I can create 2 commands in 1 class instead of 3.

What I like about it is the ease with which you can create new commands with just a little code. A little RAD, no doubt, but ultimately very useful.

I’ve concerns about supporting #[AsCommand] on public methods and allowing multiple commands on the same class/instance:

when extending from the Command class, methods like isEnabled(), interact(), or initialize() will respond to all commands defined in that class, which is undesirable

Let's just say that these functions are rarely used in final projects, and that if you want to use them, it's worth separating the commands into separate classes.

Yeah, it's an unhappy situation in my opinion. Just imagine you already have two commands in the same class, then you decide to use theinteract() method (or any of those methods), and the framework tells you to split that class; otherwise, there is an ambiguity.

I'd prefer to guide developers to happy paths where the code can evolve without problems, even if that implies adding one class per command, which is easier than before now.

Woo hoo! I lovehttps://github.com/zenstruck/console-extra, I recently ported some older code and was reminded how verbose$input->getOption('force') seems compared to declaring it with an attribute.

I figured it'd be a Symfony 8 thing, but it'd be great if it could arrive earlier, even if experimental.

I’ve concerns about supporting#[AsCommand] on public methods and allowing multiple commands on the same class/instance:

• when extending from theCommand class, methods likeisEnabled(),interact(), orinitialize() will respond to all commands defined in that class, which is undesirable
• when not extending from theCommand class, there is currently no way to inspect methods with the#[AsCommand] attribute unless we also repeat#[AsCommand] on the class itself (for autoconfiguration/tagging)
• last but not least, it won’t align with the SRP

I don't think it's a good idea to support that

Can't the behavior of theCommand::isEnabled method be achieved directly using:

#[When(...)]#[AsCommand(...)]

?

Thank you@yceruto.

I love this feature, congrats! But it's pretty hard to customize the parameters match inInvokableCommand, for example to inject a customOutputStyle we need to override a lot of logic because there is no injection ofInvokableCommand and the match is in a private method.

The obvious workaround is to injectInputInterface $input, OutputInterface $output and build the custom style.

How do you see it? Is it something we could improve?

Please create a new issue, thanks

I will resume#59794 for 7.4 - main goal is to provide an extension point for such use cases.