maybe we should make all these changes with the #AsCommand attribute in a separate PR to avoid growing this PR?

I’d actually prefer to keep all these related changes in a single PR, since they’re closely tied together. It helps keep the context in one place and makes it easier to review everything as a whole.

In any case, we can go ahead and merge this one, then open a new PR for the remaining updates.

this wont work isnt it ?
or are those console helper injectable in some ways ?

Good catch! Yes, there is a way, but I’m not sure if it’s simpler to extend Command or to get the helper via:

public function __invoke(InputInterface $input, OutputInterface $output, Application $application): int
{
    $helper = $application->getHelperSet()->get('question');

    // ...
}

Anyway, this all looks old-fashioned, because SymfonyStyle can do it better. There’s even a note right at the beginning:

.. note::

    As an alternative, consider using the
    :ref:`SymfonyStyle <symfony-style-questions>` to ask questions.

IMO, it’s not just an alternative, but the simplest way to ask questions from now on:

public function __invoke(SymfonyStyle $io): int
{
    $answer = $io->ask(...);
}

I think we should do the same here as with invokable commands: start with the simpler approach (SymfonyStyle), then mention alternatives for custom needs. wdyt @symfony/docs ?

for documentation I agree yes, basic usage then more advance 👍🏻

a question just: cant we imagine those helper as console service as injectable in the invoke method ? (can open an dedicated issue for later :))

This whole section needs updating, the text currently no longer matches the updated code example.

I think we can remove it completely, and instead merge it with the previous section. Something like

You can also use ``#[AsCommand]`` to add a description and longer help text for the command::

    // src/Command/CreateUserCommand.php

    #[AsCommand(
        name: 'app:create-user',
        description: 'Creates a new user.', // the command description shown when running "php bin/console list"
        help: 'This command allows you to create a user...', // the command help shown when running the command with the "--help" option
    )]
    class CreateUserCommand
    {
        public function __invoke(): int
        {
            // ...
        }
    }

Additionally, you can extend the :class:`Symfony\\Component\\Console\\Command\\Command`
class to leverage advanced features like lifecycle hooks (e.g.
:method:`Symfony\\Component\\Console\\Command\\Command::initialize`,
:method:`Symfony\\Component\\Console\\Command\\Command::interact`) and built-in
helpers.

The next section ("Registering the Command") also needs rework, the document now only shows the #[AsCommand] examples, so "You can register the command by adding the AsCommand attribute to it:" is out of place now.

However, we need to document the final paragraph ("If you can't use PHP attributes, register the command as a service [...]") somewhere in this article I think.

This paragraph needs rework, it talks about the execute() method which no longer exists in the example.

We reuse this command in the example below to configure it using the console.command tag. Is this tag compatible with non-Command classes?

This PR doesn't update https://symfony.com/doc/current/console/input.html (not sure if that is intentional). This means that we never documented #[Argument] or #[Option].

I don't think it's a good idea to update other examples with these attributes as long as we don't document the attributes themselves.