@weaverryan I added it in the cookbook but I'm not sure about its location. Currently, all console cookbook entries are about the console in the full stack framework. This article is about the standalone component so it may be better to move it to the component documentation. what do you think about it ?

@stof I think components/console is a better location.

Hey Stof!

I was waiting for someone to submit a PR like this, and of course it's you first :). This is the first entry that is really a "cookbook for the components" (since of course the normal cookbook is entirely for the framework). I agree with @wouterj that right now the best spot for this is in the components section. Fortunately, each component is still small enough that it should be pretty easy to find these other docs. I also think that when we have entries like this in the components docs, then we should have a "Learn More" section at the bottom of the main component's entry which lists these documents - similar to what we do already in the book.

So, if you agre @stof, can you move it to be a component?

Thanks as always!

@weaverryan done. Btw, the Console component deserves many such articles, as it is really separate from others. And this is especially true now that people start documenting the console helpers, to avoid having the main page becoming too big.
I will let you manage the Learn more links.

Hey Stof!

I've added the "Learn More" section. This is our best model so far with how we should organize the component documentation (and really, certain chapters in the book should be shorter, with more inter-linking to cookbook articles).

Once we figure out #1822, we definitely should refactor to have a dedicated section for each helper, and then add cross-links from other places in the docs - like the How to create a Console Command Cookbook entry - to these helper docs.

I'm telling you mostly so that we don't forget :)

Thanks as always!

Not sure if I did something wrong when trying to get this working but I needed to modify the initialize method of my command.

protected function initialize(InputInterface $input, OutputInterface $output)
{
        $input->setArgument('command', $this->getName());
}

Without doing this I received errors because the input argument command is never was set. This argument is required by the application definition, which gets merged into the command definition.

And what about changing the default command?
I'm coding a standalone console application with multiple commands but I want to change the default one, while keeping the list behaviour.
Since list is hardcoded in Application::doRun, this can't be achieved easily without duplicating the whole method in a subclass and changing some parts.
Is there an easier and maintainable way?