Skip to content

[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

Merged
merged 1 commit into from
Jan 20, 2021

Conversation

nicolas-grekas
Copy link
Member

@nicolas-grekas nicolas-grekas commented Jan 15, 2021

Q A
Branch? 5.x
Bug fix? no
New feature? yes
Deprecations? no
Tickets Fix #33804
License MIT
Doc PR -

This PR improves the way one can describe a command so that the list command can be made lazy:

  • when provided using the $defaultName property or the console.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.
  • a new $defaultDescription static property and a new description 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 and aliases 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.

@chalasr
Copy link
Member

chalasr commented Jan 15, 2021

Looks really nice, thank you.
I'm going to challenge the new convention for hidden commands as I had to stare at it for a while before getting what it means. I'm not sure that the command visibility should be defined through its name, at least it's not obvious that an empty string before the first separator should be the way to control it.
Could we use a special char in front of the name (. ?) or add another static prop+tag attr?

@nicolas-grekas
Copy link
Member Author

Not hidden:
$defaultName = 'app:foo|foo'

Hidden:
$defaultName = '|app:foo|goo'

I don't think this is worth adding another static property.

@nicolas-grekas nicolas-grekas changed the title [Console] enable describing commands in ways that makes the list command lazy [Console] enable describing commands in ways that make the list command lazy Jan 15, 2021
@javiereguiluz
Copy link
Member

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.

@nicolas-grekas
Copy link
Member Author

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.

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.

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?

@noniagriconomie
Copy link
Contributor

nice to have this lazy feature to be added :)

my 2cts, why not .app:foo|foo for hidden? as a hidden Unix file for example

that way:

  • the | for separating command name first and aliases next
  • the . to hide the command

@jderusse
Copy link
Member

Instead of adding static property for everything, what's about making the method configure static?.

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(...)
    ;
  }
}

@nicolas-grekas
Copy link
Member Author

@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.

@nicolas-grekas
Copy link
Member Author

why not .app:foo|foo for hidden

because it's not better than the current proposal?

@jderusse
Copy link
Member

@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.

Isn't it addressed by the second part of my comment?

@nicolas-grekas
Copy link
Member Author

@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.

@natewiebe13
Copy link
Contributor

why not .app:foo|foo for hidden

because it's not better than the current 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.

@stof
Copy link
Member

stof commented Jan 15, 2021

@natewiebe13 but this reserves 2 chars (. and |) which cannot be used anymore in command names. | is fine as a reserved char is fine, as no one would use that char in their command name: | is a special char in all shells, and so using the command would require escaping it all the time.
But . has no special meaning and could totally be used in command names (even though that's not the recommended Symfony naming convention).

@stof
Copy link
Member

stof commented Jan 15, 2021

Isn't it addressed by the second part of my comment?

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.

@natewiebe13
Copy link
Contributor

natewiebe13 commented Jan 15, 2021

@natewiebe13 but this reserves 2 chars (. and |) which cannot be used anymore in command names. | is fine as a reserved char is fine, as no one would use that char in their command name: | is a special char in all shells, and so using the command would require escaping it all the time.
But . has no special meaning and could totally be used in command names (even though that's not the recommended Symfony naming convention).

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
For example, I'd still think .app.do-something would still be valid as app.do-something. It would just be hidden.

@stof
Copy link
Member

stof commented Jan 15, 2021

@nicolas-grekas there is still the issue of Command::isEnabled() though. It impacts list as well.

@nicolas-grekas
Copy link
Member Author

there is still the issue of Command::isEnabled() though. It impacts list as well.

Isn't this covered? See the implementation of isEnabled(). Otherwise, I may have missed what you meant.

@nicolas-grekas
Copy link
Member Author

I wouldn't expect any periods in the command name to cause issues, just if the name was prefixed by a period.

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.

@stof
Copy link
Member

stof commented Jan 15, 2021

Isn't this covered? See the implementation of isEnabled(). Otherwise, I may have missed what you meant.

disabled commands are excluded by list

@ro0NL
Copy link
Contributor

ro0NL commented Jan 15, 2021

@stof pipe char may be quoted 😅 im fine with it, otherwise static $defaultAliases & co

symfony-splitter pushed a commit to symfony/framework-bundle that referenced this pull request Jan 20, 2021
…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
reviewtypo3org pushed a commit to TYPO3/typo3 that referenced this pull request Feb 4, 2021
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>
TYPO3IncTeam pushed a commit to TYPO3-CMS/core that referenced this pull request Feb 4, 2021
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>
reviewtypo3org pushed a commit to TYPO3/typo3 that referenced this pull request Feb 4, 2021
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>
TYPO3IncTeam pushed a commit to TYPO3-CMS/core that referenced this pull request Feb 4, 2021
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>
bnf added a commit to bnf/typo3 that referenced this pull request Feb 4, 2021
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
bnf added a commit to bnf/typo3 that referenced this pull request Feb 4, 2021
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
reviewtypo3org pushed a commit to TYPO3/typo3 that referenced this pull request Feb 9, 2021
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>
TYPO3IncTeam pushed a commit to TYPO3-CMS/backend that referenced this pull request Feb 9, 2021
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>
TYPO3IncTeam pushed a commit to TYPO3-CMS/core that referenced this pull request Feb 9, 2021
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>
TYPO3IncTeam pushed a commit to TYPO3-CMS/extensionmanager that referenced this pull request Feb 9, 2021
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>
TYPO3IncTeam pushed a commit to TYPO3-CMS/impexp that referenced this pull request Feb 9, 2021
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>
TYPO3IncTeam pushed a commit to TYPO3-CMS/install that referenced this pull request Feb 9, 2021
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>
TYPO3IncTeam pushed a commit to TYPO3-CMS/lowlevel that referenced this pull request Feb 9, 2021
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>
TYPO3IncTeam pushed a commit to TYPO3-CMS/redirects that referenced this pull request Feb 9, 2021
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>
TYPO3IncTeam pushed a commit to TYPO3-CMS/scheduler that referenced this pull request Feb 9, 2021
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>
TYPO3IncTeam pushed a commit to TYPO3-CMS/workspaces that referenced this pull request Feb 9, 2021
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>
chalasr added a commit that referenced this pull request Feb 19, 2021
… 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
nicolas-grekas added a commit that referenced this pull request Mar 17, 2021
…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
@fabpot fabpot mentioned this pull request Apr 18, 2021
tucksaun added a commit to tucksaun/SwarrotBundle that referenced this pull request Mar 2, 2022
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
tucksaun added a commit to tucksaun/SwarrotBundle that referenced this pull request Mar 2, 2022
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
tucksaun added a commit to tucksaun/SwarrotBundle that referenced this pull request Mar 2, 2022
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
tucksaun added a commit to tucksaun/SwarrotBundle that referenced this pull request Mar 2, 2022
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Console] Distinguish definition of a command from its execution