[Console] Initiative: rework the console component

Description
The console component is widely used and loved by many.
It does a lot of work and makes adding console commands quite easy for developers if you stick to the documentation.

However, if you want to do some more niche things with commands, you start running into problems.
The initial commit is from 2010, making this component 11 years old already.
Given the recent rework of the security component, I propose a similar initiative for the console component.

I would love to hear the opinion of the symfony core team on this topic.
If you are in favor of a rework, maybe we can put together a working group and discuss the direction this should take.
Of course we have to consider backwards compatibility, clear updated documentation and an easy upgrade path.

With the experience of the security component rework, I would love to get input from @wouterj and @weaverryan

Related: #34907 (comment)

2 thoughts on “[Console] Initiative: rework the console component

  1. Age is not a good reason to rebuild something completely. Especially for components that are used as much as the Console component, rewriting something from the ground up has a massive impact on the PHP ecosystem. As such, I consider rewriting Console almost a no-go.

    That said, if there is a real scenario that doesn’t yet work with Console component, it’s good to tackle that specific issue. Rebuilding Security was never the goal, the goal was improving the Guard interface and making sure internals was using Guards. The means to achieve that goal was a rewrite of the authentication manager.

    I do not understand the use-cases in #34907. Or more specifically: instead of decoration, can’t these usecases be fixed by using the console events? Note that current Console component is quite flexible. E.g. Behat has implemented its own “cli controller” concept on top of the Console component: https://github.com/Behat/Behat/blob/master/src/Behat/Testwork/Cli/Command.php

  2. In open source communities, it’s often hard to judge whether a change is needed or not. Please show some real life problems and proposed fixes when you propose a change (such like this one). That makes it easier to judge whether changes are needed.

    For now, and forgive me to be a bit holding back here, I see mostly ideological arguments for change (I’ve never found a problem with extending the – somewhat large – Command class in my applications). Imho, ideological ideas are not worth changing a component that has such a large popularity.

    On the other hand, “Utilize String component to better deal with emojis and non-latin characters” seems like a real use-case. In my opinion, this continues the work that has been put on true color support in the 5.2 console component. Making sure Console can deal with special characters/emojis can be great 5.x feature (that is, I don’t know what the current problems are with emojis in the Console component and if String can fix those, but that’s worth a more specialized issue).