Collect ideas for CLI commands

[froschdesign]

"Must have" CLI commands

We want to speed up the development of CLI support in components and we collect ideas and suggestions which commands are needed or desired. As a first step, we want to develop a list of "must have" CLI commands, like create module, controller, controller action, etc.

Your ideas and requirements are needed

Please add your ideas to this discussion or open new ones.
(We assume that there are already a lot of ideas for the various commands, therefore a rough grouping by topic or component would be helpful.)

Project

We already create a project (as draft!) to collect the commands. In this way we can track the progress, create issue reports in the related issue trackers and give an overview of what is planned and what is already on the way.
We will adopt new ideas for commands and update the project regularly.

We love every contribution!

[internalsystemerror]

I have an aversion to including code in components where it won't be used. So I prefer for example, adapters into satellite repositories, fixtures into their own repositories etc. So take what I say with that bias in mind.

I would much prefer to have any new CLI tooling, not be included in the components themselves, but as a separate package that I can install under require-dev, ensuring it never reaches our production servers. My suggestion would be laminas/laminas-tooling for example, to follow how mezzio/mezzio-tooling is set up. Both could then rely on laminas/laminas-cli as the base.

The suggested commands listed so far I offer my support to, it looks like a good list and I'm unsure what else we could add to it. Aside from maybe adding commands to allow you to create your own custom FormElement, Validator or Filter, where creating a custom class is a common occurrence for users, even if each user only does it sparingly.

[froschdesign]

I would much prefer to have any new CLI tooling, not be included in the components themselves, but as a separate package that I can install under require-dev, ensuring it never reaches our production servers.

laminas-cache is a component that already contains a command. laminas-cli is here a dev dependency and the config provider checks for the Symfony\Component\Console\Command\Command to add the command or not:

if (class_exists(Command::class)) {
    $dependencies['factories'] += [
        DeprecatedStorageFactoryConfigurationCheckCommand::class
            => DeprecatedStorageFactoryConfigurationCheckCommandFactory::class,
    ];
}

https://github.com/laminas/laminas-cache/blob/e2c9fef1f149655816035cc17d3b0f45e9e80a44/src/ConfigProvider.php#L53-L58

Aside from maybe adding commands to allow you to create your own custom FormElement, Validator or Filter, where creating a custom class is a common occurrence for users, even if each user only does it sparingly.

I have tried to collect the "must-have" commands, but you are right, commands to create custom implementations should also exist in the future.

[internalsystemerror]

laminas-cache is a component that already contains a command. laminas-cli is here a dev dependency and the config provider checks for the Symfony\Component\Console\Command\Command to add the command or not

I understand, and I'm just expressing my desire that I'd rather it didn't. Maybe it's being overly cautious of me, but I am wary of what exactly I put into a production server. Code that's designed for use in development should stay out of production as a general rule (a personal rule).

[internalsystemerror]

For instance, this would be added into configuration on a couple of our apps because we use a symfony command to run workers that monitor AMQP queues

[froschdesign]

Code that's designed for use in development should stay out of production as a general rule (a personal rule).

Sorry for the misunderstanding. I only wanted to refer to an already existing implementation, this does not mean that we have to do it that way in principle.

There is another rule: the documentation must be added to this repository, which also contains the associated code.
But in this case, the CLI commands must be shown in the same documentation in which the related component is described. A reader should not have to switch between two different documentations to create a form via CLI command.
This means that we have to extend the build process of the documentation to include documentations from other repositories. (I think cloning the related repository via Git is the best option here).

[internalsystemerror]

Yeah I agree on the documentation, it makes total sense and I can't see any reason why not to. My opinion on the CLI code, I expect that others may disagree there though. At the end of the day it's not my call and I'll help with whatever gets decided.

[ALTAMASH80]

I've got a question regarding the suggested CLI-Command. Will this be a new package? If not why? As people in the past have found some impressive ways to bash Laminas MVC by stating it is way too hard and so on and so forth. If it is decided that these commands will be part of Laminas-CLI then people will complain that I'm using Laminas-CLI as an individual component and I'm not using the Laminas-MVC, therefore it is consuming a trillion bytes of memory, therefore, it is a very bad package and the list of arguments will go on.

So, is my point of view correct or it is an illusion? Thanks!

[boesing]

It depends on what these commands are used for.
We already ship component specific CLI commands such as cache configuration validation, servicemanager factory generation, etc. via the corresponding packages. Since CLI components are not part of a typical application (besides CLI-only applications ofc), laminas-cli is not required there but suggested (via opt-in) so that you can consume the CLI command if needed and projects which do not bother with CLI can still just use the component without CLI support.