-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Console] enable describing commands in ways that make the list
command lazy
#39851
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Looks really nice, thank you. |
Not hidden: Hidden: I don't think this is worth adding another static property. |
list
command lazylist
command lazy
39fab1f
to
a340975
Compare
I don't like much the proposed convention to define a command as hidden because it's not self-explanatory. As an alternative, would it be possible to store the list of commands in the cache dir while "compiling" the app? Same as we do with routes. Thanks. |
IMHO, there is no need to optimize for setting the "hidden" flag, as that's not a mainstream feature. It's readable enough as is.
Sorry, I don't get what you mean, can you please describe your idea a bit more? What's the DX that goes with this? |
nice to have this lazy feature to be added :) my 2cts, why not that way:
|
Instead of adding static property for everything, what's about making the method class AppCommand extends Command implements StaticCommandDescribedInterface
{
public static function configure(): CommandDescription
{
return new CommandDescription('app:test')
->setDefinition()
->setHelp()
->addInput(...)
;
}
} class that can't be static and need internal service to resolve could implement another interface (that is incompatible with the previous) class AppCommand extends Command implements InstanceCommandDescribedInterface
{
public function configure(): CommandDescription
{
return new CommandDescription('app:test')
->setDefinition()
->setHelp($this->getHint())
->addInput(...)
;
}
} |
@jderusse that would kill the possibility to make the command configuration sensitive to constructor argument. Aka that could kill a lot of flexibility in the class. Yes, we don't use/need that in typical Symfony DI, but the console component is very much used standalone. We should be sure to not degrade it's DX when used outside of a typical Symfony stack. From a SOLID pov, static methods are just bad. |
because it's not better than the current proposal? |
Isn't it addressed by the second part of my comment? |
@jderusse to not break BC, we should rather make static version opt-in. I don't know where this could lead, in terms of BC impact for example. Of course, feel free to give it a try, as I did here with my proposal. |
I think it's more clear as to what the intention is. Prefixing with a dot is common convention for hiding a file/directory in Linux and Mac OS. Whereas using the separator as a prefix, it isn't clear without first reading documentation that it's hiding the command instead of just a typo. |
@natewiebe13 but this reserves 2 chars ( |
but that forbids lazy-loading these commands then, while the use case for relying in the constructor arguments in the configuration is much more likely to be related to configuring options or arguments than the description. |
But wouldn't that just be for the first char in a command name? I wouldn't expect any periods in the command name to cause issues, just if the name was prefixed by a period. Edit |
@nicolas-grekas there is still the issue of |
Isn't this covered? See the implementation of |
Until one will report a BC break :) This happens all the time when we do such assumptions. Honestly, the leading pipe is fine, it's as readable. Everything needs to be taught anyway. |
disabled commands are excluded by |
@stof pipe char may be quoted 😅 im fine with it, otherwise |
…nicolas-grekas) This PR was merged into the 5.3-dev branch. Discussion ---------- [Console] add option `--short` to the `list` command | Q | A | ------------- | --- | Branch? | 5.x | Bug fix? | no | New feature? | yes | Deprecations? | no | Tickets | - | License | MIT | Doc PR | - This PR is a follow up of symfony/symfony#39851, triggered by @wouterj's comment at symfony/symfony#39851 (review). This new option should enable creating fast shell auto-completion, by allowing the `list` command to run fast. Commits ------- 81d5728f4a [Console] add option `--short` to the `list` command
With the Symfony PR symfony/symfony#39851 new depndency injection console.command tag properties are supported, which allow to inject the description and the hidden state into console commands. In order to maintain a consistent console.command DI tag syntax between Symfony and TYPO3 core, we now add forward compatibility for this change. Releases: master, 10.4 Resolves: #93425 Related: #93174 Change-Id: Ie5dac65deaede2099f2d337466295bd2815ce918 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67639 Tested-by: TYPO3com <noreply@typo3.com> Tested-by: Helmut Hummel <typo3@helhum.io> Tested-by: Benni Mack <benni@typo3.org> Tested-by: Benjamin Franzke <bfr@qbus.de> Reviewed-by: Helmut Hummel <typo3@helhum.io> Reviewed-by: Benni Mack <benni@typo3.org> Reviewed-by: Benjamin Franzke <bfr@qbus.de>
With the Symfony PR symfony/symfony#39851 new depndency injection console.command tag properties are supported, which allow to inject the description and the hidden state into console commands. In order to maintain a consistent console.command DI tag syntax between Symfony and TYPO3 core, we now add forward compatibility for this change. Releases: master, 10.4 Resolves: #93425 Related: #93174 Change-Id: Ie5dac65deaede2099f2d337466295bd2815ce918 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67639 Tested-by: TYPO3com <noreply@typo3.com> Tested-by: Helmut Hummel <typo3@helhum.io> Tested-by: Benni Mack <benni@typo3.org> Tested-by: Benjamin Franzke <bfr@qbus.de> Reviewed-by: Helmut Hummel <typo3@helhum.io> Reviewed-by: Benni Mack <benni@typo3.org> Reviewed-by: Benjamin Franzke <bfr@qbus.de>
With the Symfony PR symfony/symfony#39851 new depndency injection console.command tag properties are supported, which allow to inject the description and the hidden state into console commands. In order to maintain a consistent console.command DI tag syntax between Symfony and TYPO3 core, we now add forward compatibility for this change. Releases: master, 10.4 Resolves: #93425 Related: #93174 Change-Id: Ie5dac65deaede2099f2d337466295bd2815ce918 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67600 Tested-by: TYPO3com <noreply@typo3.com> Tested-by: Benjamin Franzke <bfr@qbus.de> Reviewed-by: Benjamin Franzke <bfr@qbus.de>
With the Symfony PR symfony/symfony#39851 new depndency injection console.command tag properties are supported, which allow to inject the description and the hidden state into console commands. In order to maintain a consistent console.command DI tag syntax between Symfony and TYPO3 core, we now add forward compatibility for this change. Releases: master, 10.4 Resolves: #93425 Related: #93174 Change-Id: Ie5dac65deaede2099f2d337466295bd2815ce918 Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67600 Tested-by: TYPO3com <noreply@typo3.com> Tested-by: Benjamin Franzke <bfr@qbus.de> Reviewed-by: Benjamin Franzke <bfr@qbus.de>
Based on the configuration syntax of the Symfony Console feature symfony/symfony#39851 …but implemented differently, using a registry pattern rather then a lazy-object pattern (like symfony does). Main motiviation for the registry pattern is following: Symfony LazyCommand wrappers add quite some complexity only for the sake of the list command, we already got lazy commands (in terms of execution) as our CommandRegistry implements the ConfigurationLoaderInterface that has been introduced by 2017 to add support for lazy commands. Now, that means we already got a registry for lazy commands, so it is logical to add lazy description handling there as well. We want to assure that the command list will never instantiate any commands. This is in constrast to the Symfony core LazyCommand approach, where legacy commands, that do not provide a compile time description, would still be instantiated during console command list. Also commands that return false in `isEnabled()` are now listed. That means enabled state is only evaluated during runtime. Therefore the special `dumpautoload` command is transformed into a lowlevel command in order to be hidden dependending on being run in composer-mode or not. Releases: master Resolves: #93174 Change-Id: Ifa68404cc81c64a335be30f2263a7eb17de0624d
Based on the configuration syntax of the Symfony Console feature symfony/symfony#39851 …but implemented differently, using a registry pattern rather then a lazy-object pattern (like symfony does). Main motiviation for the registry pattern is following: Symfony LazyCommand wrappers add quite some complexity only for the sake of the list command, we already got lazy commands (in terms of execution) as our CommandRegistry implements the ConfigurationLoaderInterface that has been introduced by 2017 to add support for lazy commands. Now, that means we already got a registry for lazy commands, so it is logical to add lazy description handling there as well. We want to assure that the command list will never instantiate any commands. This is in constrast to the Symfony core LazyCommand approach, where legacy commands, that do not provide a compile time description, would still be instantiated during console command list. Also commands that return false in `isEnabled()` are now listed. That means enabled state is only evaluated during runtime. Therefore the special `dumpautoload` command is transformed into a lowlevel command in order to be hidden dependending on being run in composer-mode or not. Releases: master Resolves: #93174 Change-Id: Ifa68404cc81c64a335be30f2263a7eb17de0624d
Based on the configuration syntax of the Symfony Console feature symfony/symfony#39851 …but implemented differently, using a registry pattern rather then a lazy-object pattern (like symfony does). Main motiviation for the registry pattern is following: Symfony LazyCommand wrappers add quite some complexity only for the sake of the list command, we already got lazy commands (in terms of execution) as our CommandRegistry implements the ConfigurationLoaderInterface that has been introduced by 2017 to add support for lazy commands. Now, that means we already got a registry for lazy commands, so it is logical to add lazy description handling there as well. We want to assure that the command list will never instantiate any commands. This is in constrast to the Symfony core LazyCommand approach, where legacy commands, that do not provide a compile time description, would still be instantiated during console command list. Also commands that return false in `isEnabled()` are now listed. That means enabled state is only evaluated during runtime. Therefore the special `dumpautoload` command is transformed into a lowlevel command in order to be hidden dependending on being run in composer-mode or not. Releases: master Resolves: #93174 Change-Id: Ifa68404cc81c64a335be30f2263a7eb17de0624d Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67635 Tested-by: TYPO3com <noreply@typo3.com> Tested-by: core-ci <typo3@b13.com> Tested-by: Benni Mack <benni@typo3.org> Tested-by: Helmut Hummel <typo3@helhum.io> Reviewed-by: Benni Mack <benni@typo3.org> Reviewed-by: Helmut Hummel <typo3@helhum.io>
Based on the configuration syntax of the Symfony Console feature symfony/symfony#39851 …but implemented differently, using a registry pattern rather then a lazy-object pattern (like symfony does). Main motiviation for the registry pattern is following: Symfony LazyCommand wrappers add quite some complexity only for the sake of the list command, we already got lazy commands (in terms of execution) as our CommandRegistry implements the ConfigurationLoaderInterface that has been introduced by 2017 to add support for lazy commands. Now, that means we already got a registry for lazy commands, so it is logical to add lazy description handling there as well. We want to assure that the command list will never instantiate any commands. This is in constrast to the Symfony core LazyCommand approach, where legacy commands, that do not provide a compile time description, would still be instantiated during console command list. Also commands that return false in `isEnabled()` are now listed. That means enabled state is only evaluated during runtime. Therefore the special `dumpautoload` command is transformed into a lowlevel command in order to be hidden dependending on being run in composer-mode or not. Releases: master Resolves: #93174 Change-Id: Ifa68404cc81c64a335be30f2263a7eb17de0624d Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67635 Tested-by: TYPO3com <noreply@typo3.com> Tested-by: core-ci <typo3@b13.com> Tested-by: Benni Mack <benni@typo3.org> Tested-by: Helmut Hummel <typo3@helhum.io> Reviewed-by: Benni Mack <benni@typo3.org> Reviewed-by: Helmut Hummel <typo3@helhum.io>
Based on the configuration syntax of the Symfony Console feature symfony/symfony#39851 …but implemented differently, using a registry pattern rather then a lazy-object pattern (like symfony does). Main motiviation for the registry pattern is following: Symfony LazyCommand wrappers add quite some complexity only for the sake of the list command, we already got lazy commands (in terms of execution) as our CommandRegistry implements the ConfigurationLoaderInterface that has been introduced by 2017 to add support for lazy commands. Now, that means we already got a registry for lazy commands, so it is logical to add lazy description handling there as well. We want to assure that the command list will never instantiate any commands. This is in constrast to the Symfony core LazyCommand approach, where legacy commands, that do not provide a compile time description, would still be instantiated during console command list. Also commands that return false in `isEnabled()` are now listed. That means enabled state is only evaluated during runtime. Therefore the special `dumpautoload` command is transformed into a lowlevel command in order to be hidden dependending on being run in composer-mode or not. Releases: master Resolves: #93174 Change-Id: Ifa68404cc81c64a335be30f2263a7eb17de0624d Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67635 Tested-by: TYPO3com <noreply@typo3.com> Tested-by: core-ci <typo3@b13.com> Tested-by: Benni Mack <benni@typo3.org> Tested-by: Helmut Hummel <typo3@helhum.io> Reviewed-by: Benni Mack <benni@typo3.org> Reviewed-by: Helmut Hummel <typo3@helhum.io>
Based on the configuration syntax of the Symfony Console feature symfony/symfony#39851 …but implemented differently, using a registry pattern rather then a lazy-object pattern (like symfony does). Main motiviation for the registry pattern is following: Symfony LazyCommand wrappers add quite some complexity only for the sake of the list command, we already got lazy commands (in terms of execution) as our CommandRegistry implements the ConfigurationLoaderInterface that has been introduced by 2017 to add support for lazy commands. Now, that means we already got a registry for lazy commands, so it is logical to add lazy description handling there as well. We want to assure that the command list will never instantiate any commands. This is in constrast to the Symfony core LazyCommand approach, where legacy commands, that do not provide a compile time description, would still be instantiated during console command list. Also commands that return false in `isEnabled()` are now listed. That means enabled state is only evaluated during runtime. Therefore the special `dumpautoload` command is transformed into a lowlevel command in order to be hidden dependending on being run in composer-mode or not. Releases: master Resolves: #93174 Change-Id: Ifa68404cc81c64a335be30f2263a7eb17de0624d Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67635 Tested-by: TYPO3com <noreply@typo3.com> Tested-by: core-ci <typo3@b13.com> Tested-by: Benni Mack <benni@typo3.org> Tested-by: Helmut Hummel <typo3@helhum.io> Reviewed-by: Benni Mack <benni@typo3.org> Reviewed-by: Helmut Hummel <typo3@helhum.io>
Based on the configuration syntax of the Symfony Console feature symfony/symfony#39851 …but implemented differently, using a registry pattern rather then a lazy-object pattern (like symfony does). Main motiviation for the registry pattern is following: Symfony LazyCommand wrappers add quite some complexity only for the sake of the list command, we already got lazy commands (in terms of execution) as our CommandRegistry implements the ConfigurationLoaderInterface that has been introduced by 2017 to add support for lazy commands. Now, that means we already got a registry for lazy commands, so it is logical to add lazy description handling there as well. We want to assure that the command list will never instantiate any commands. This is in constrast to the Symfony core LazyCommand approach, where legacy commands, that do not provide a compile time description, would still be instantiated during console command list. Also commands that return false in `isEnabled()` are now listed. That means enabled state is only evaluated during runtime. Therefore the special `dumpautoload` command is transformed into a lowlevel command in order to be hidden dependending on being run in composer-mode or not. Releases: master Resolves: #93174 Change-Id: Ifa68404cc81c64a335be30f2263a7eb17de0624d Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67635 Tested-by: TYPO3com <noreply@typo3.com> Tested-by: core-ci <typo3@b13.com> Tested-by: Benni Mack <benni@typo3.org> Tested-by: Helmut Hummel <typo3@helhum.io> Reviewed-by: Benni Mack <benni@typo3.org> Reviewed-by: Helmut Hummel <typo3@helhum.io>
Based on the configuration syntax of the Symfony Console feature symfony/symfony#39851 …but implemented differently, using a registry pattern rather then a lazy-object pattern (like symfony does). Main motiviation for the registry pattern is following: Symfony LazyCommand wrappers add quite some complexity only for the sake of the list command, we already got lazy commands (in terms of execution) as our CommandRegistry implements the ConfigurationLoaderInterface that has been introduced by 2017 to add support for lazy commands. Now, that means we already got a registry for lazy commands, so it is logical to add lazy description handling there as well. We want to assure that the command list will never instantiate any commands. This is in constrast to the Symfony core LazyCommand approach, where legacy commands, that do not provide a compile time description, would still be instantiated during console command list. Also commands that return false in `isEnabled()` are now listed. That means enabled state is only evaluated during runtime. Therefore the special `dumpautoload` command is transformed into a lowlevel command in order to be hidden dependending on being run in composer-mode or not. Releases: master Resolves: #93174 Change-Id: Ifa68404cc81c64a335be30f2263a7eb17de0624d Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67635 Tested-by: TYPO3com <noreply@typo3.com> Tested-by: core-ci <typo3@b13.com> Tested-by: Benni Mack <benni@typo3.org> Tested-by: Helmut Hummel <typo3@helhum.io> Reviewed-by: Benni Mack <benni@typo3.org> Reviewed-by: Helmut Hummel <typo3@helhum.io>
Based on the configuration syntax of the Symfony Console feature symfony/symfony#39851 …but implemented differently, using a registry pattern rather then a lazy-object pattern (like symfony does). Main motiviation for the registry pattern is following: Symfony LazyCommand wrappers add quite some complexity only for the sake of the list command, we already got lazy commands (in terms of execution) as our CommandRegistry implements the ConfigurationLoaderInterface that has been introduced by 2017 to add support for lazy commands. Now, that means we already got a registry for lazy commands, so it is logical to add lazy description handling there as well. We want to assure that the command list will never instantiate any commands. This is in constrast to the Symfony core LazyCommand approach, where legacy commands, that do not provide a compile time description, would still be instantiated during console command list. Also commands that return false in `isEnabled()` are now listed. That means enabled state is only evaluated during runtime. Therefore the special `dumpautoload` command is transformed into a lowlevel command in order to be hidden dependending on being run in composer-mode or not. Releases: master Resolves: #93174 Change-Id: Ifa68404cc81c64a335be30f2263a7eb17de0624d Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67635 Tested-by: TYPO3com <noreply@typo3.com> Tested-by: core-ci <typo3@b13.com> Tested-by: Benni Mack <benni@typo3.org> Tested-by: Helmut Hummel <typo3@helhum.io> Reviewed-by: Benni Mack <benni@typo3.org> Reviewed-by: Helmut Hummel <typo3@helhum.io>
Based on the configuration syntax of the Symfony Console feature symfony/symfony#39851 …but implemented differently, using a registry pattern rather then a lazy-object pattern (like symfony does). Main motiviation for the registry pattern is following: Symfony LazyCommand wrappers add quite some complexity only for the sake of the list command, we already got lazy commands (in terms of execution) as our CommandRegistry implements the ConfigurationLoaderInterface that has been introduced by 2017 to add support for lazy commands. Now, that means we already got a registry for lazy commands, so it is logical to add lazy description handling there as well. We want to assure that the command list will never instantiate any commands. This is in constrast to the Symfony core LazyCommand approach, where legacy commands, that do not provide a compile time description, would still be instantiated during console command list. Also commands that return false in `isEnabled()` are now listed. That means enabled state is only evaluated during runtime. Therefore the special `dumpautoload` command is transformed into a lowlevel command in order to be hidden dependending on being run in composer-mode or not. Releases: master Resolves: #93174 Change-Id: Ifa68404cc81c64a335be30f2263a7eb17de0624d Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67635 Tested-by: TYPO3com <noreply@typo3.com> Tested-by: core-ci <typo3@b13.com> Tested-by: Benni Mack <benni@typo3.org> Tested-by: Helmut Hummel <typo3@helhum.io> Reviewed-by: Benni Mack <benni@typo3.org> Reviewed-by: Helmut Hummel <typo3@helhum.io>
Based on the configuration syntax of the Symfony Console feature symfony/symfony#39851 …but implemented differently, using a registry pattern rather then a lazy-object pattern (like symfony does). Main motiviation for the registry pattern is following: Symfony LazyCommand wrappers add quite some complexity only for the sake of the list command, we already got lazy commands (in terms of execution) as our CommandRegistry implements the ConfigurationLoaderInterface that has been introduced by 2017 to add support for lazy commands. Now, that means we already got a registry for lazy commands, so it is logical to add lazy description handling there as well. We want to assure that the command list will never instantiate any commands. This is in constrast to the Symfony core LazyCommand approach, where legacy commands, that do not provide a compile time description, would still be instantiated during console command list. Also commands that return false in `isEnabled()` are now listed. That means enabled state is only evaluated during runtime. Therefore the special `dumpautoload` command is transformed into a lowlevel command in order to be hidden dependending on being run in composer-mode or not. Releases: master Resolves: #93174 Change-Id: Ifa68404cc81c64a335be30f2263a7eb17de0624d Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67635 Tested-by: TYPO3com <noreply@typo3.com> Tested-by: core-ci <typo3@b13.com> Tested-by: Benni Mack <benni@typo3.org> Tested-by: Helmut Hummel <typo3@helhum.io> Reviewed-by: Benni Mack <benni@typo3.org> Reviewed-by: Helmut Hummel <typo3@helhum.io>
Based on the configuration syntax of the Symfony Console feature symfony/symfony#39851 …but implemented differently, using a registry pattern rather then a lazy-object pattern (like symfony does). Main motiviation for the registry pattern is following: Symfony LazyCommand wrappers add quite some complexity only for the sake of the list command, we already got lazy commands (in terms of execution) as our CommandRegistry implements the ConfigurationLoaderInterface that has been introduced by 2017 to add support for lazy commands. Now, that means we already got a registry for lazy commands, so it is logical to add lazy description handling there as well. We want to assure that the command list will never instantiate any commands. This is in constrast to the Symfony core LazyCommand approach, where legacy commands, that do not provide a compile time description, would still be instantiated during console command list. Also commands that return false in `isEnabled()` are now listed. That means enabled state is only evaluated during runtime. Therefore the special `dumpautoload` command is transformed into a lowlevel command in order to be hidden dependending on being run in composer-mode or not. Releases: master Resolves: #93174 Change-Id: Ifa68404cc81c64a335be30f2263a7eb17de0624d Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67635 Tested-by: TYPO3com <noreply@typo3.com> Tested-by: core-ci <typo3@b13.com> Tested-by: Benni Mack <benni@typo3.org> Tested-by: Helmut Hummel <typo3@helhum.io> Reviewed-by: Benni Mack <benni@typo3.org> Reviewed-by: Helmut Hummel <typo3@helhum.io>
… commands on PHP 8 (nicolas-grekas) This PR was merged into the 5.3-dev branch. Discussion ---------- [Console] Add `ConsoleCommand` attribute for declaring commands on PHP 8 | Q | A | ------------- | --- | Branch? | 5.x | Bug fix? | no | New feature? | yes | Deprecations? | no | Tickets | - | License | MIT | Doc PR | - Builds on #39851 On PHP8, this PR will allow using an attribute instead of the public static properties for the name and the description. ```php #[ConsoleCommand( name: 'app:my-command', description: '🌈', hidden: true, aliases: ['🌈'], )] class MyCommand extends Command { } ``` Commits ------- 0cbc9cc [Console] Add `ConsoleCommand` attribute for declaring commands on PHP 8
…nd in console (DemigodCode) This PR was merged into the 5.3-dev branch. Discussion ---------- [DebugBundle] Remove warning of ServerDumpPlaceholderCommand in console | Q | A | ------------- | --- | Branch? | 5.2.5 | Bug fix? | yes | New feature? | no | Deprecations? | no | Tickets | Fix #40495 | License | MIT | Doc PR | In 5.2.5 the console commands are lazy. (#39851) With this change the ServerDumpCommand::$defaultName is used which isn't set in the placeholder command. If no vardump-server in debug.dump_destination is defined, this will lead to a warning and not adding the command to the console list. Commits ------- 37b2a19 [DebugBundle] Add $defaultName to PlaceholderCommand
This allow Symfony to make the command lazy-loadable and thus avoiding instantiation of every processor just to list applications command. See symfony/symfony#39851 for more info
This allow Symfony to make the command lazy-loadable and thus avoiding instantiation of every processor just to list applications command. See symfony/symfony#39851 for more info
This allows Symfony to make the command lazy-loadable and thus avoiding instantiation of every processors only to list application's commands. See symfony/symfony#39851 for more info
This allows Symfony to make the command lazy-loadable and thus avoiding instantiation of every processors only to list application's commands. See symfony/symfony#39851 for more info
This PR improves the way one can describe a command so that the
list
command can be made lazy:$defaultName
property or theconsole.command
tag, the name of a command is now exploded using the|
character. The first name in the list defines the name of the command, the other ones its aliases. When the first name is the empty string, the second name is used instead, and the command is declared as hidden.$defaultDescription
static property and a newdescription
tag attribute allow for defining the commands' description while registering them.Together, this is enough to make the
list
command lazy, because this command only accesses each command's name, aliases, hidden-status, and description.On the implementation side, this PR adds a
LazyCommand
class that proxies regular commands to make them lazy for the target purpose.This PR will enable support for attributes for configuring a command name+description+etc.
e.g. using the concepts in #39804:
#[CommandAutoTag(name: 'foo:bar', desc: 'boo', hidden: true)]#
The attribute could very well split the
hidden
andaliases
settings apart - while the underlying code and pre-PHP8 apps would use the compact form, because dealing with many static properties + methods would be a maintenance pain imho.