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 the Symfony one-file demo with this approach for a single-app command, and this is the result:

<?php

require_once __DIR__.'/vendor/autoload_runtime.php';

use Symfony\Bundle\FrameworkBundle\Console\Application;
use Symfony\Bundle\FrameworkBundle\Kernel\MicroKernelTrait;
use Symfony\Component\Console\Attribute\Argument;
use Symfony\Component\Console\Attribute\AsCommand;
use Symfony\Component\Console\Style\SymfonyStyle;
use Symfony\Component\HttpKernel\Kernel;

#[AsCommand('app:start')]
class SymfonyOneFileApp extends Kernel
{
    use MicroKernelTrait;

    public function __invoke(SymfonyStyle $io, #[Argument] string $name = 'World'): void
    {
        $io->success(sprintf('Hello %s!', $name));
    }
}

return static function (array $context) {
    return new Application(new SymfonyOneFileApp($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 the Command class, methods like isEnabled(), interact(), or initialize() will respond to all commands defined in that class, which is undesirable
• when not extending from the Command 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 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.

• when not extending from the Command 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:

The registerAttributeForAutoconfiguration 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 the interact() 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 love https://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 the Command class, methods like isEnabled(), interact(), or initialize() will respond to all commands defined in that class, which is undesirable
• when not extending from the Command 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 the Command::isEnabled method be achieved directly using:

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

?

Update! Added two deprecations noticies:

• untyped parameter bound to the setCode's callable is deprecated and will throw an exception in 8.0
• returning a non-integer value from the setCode's callable is deprecated and will throw an exception in 8.0 (it's still possible to return void)

Thank you @yceruto.