Habitual way of usage (not coding) such as command/action is easy to keep and there’s no need for a wrapper in this case. It is about command naming. Same about keeping option names and arguments order.
Keeping code style similar to Yii 2 is possible but I’m not sure it is a good idea.
By “no need to implement it” I’ve meant terminal interaction itself. We still have to create a wrapper to merge configs, lazy command registration, DI container integration etc.
It’s not a bad idea, but with this approach we could replace most parts of Yii with external libraries (many from symfony).
Infact we have discussions about validators, httpclient, console, etc… I think we should continue to develop our own implementations, otherwise we will have Yiimfony
The root of the problem here is not enough programmers to develop & maintain Yii2 own solution(s) in a long run. Since Samdark is almost alone working on the framework, permanent issues with financing the development, no business or marketing model … it is significant time-saver for current team just to overtake proven solution(s). Yiimfony ha*ha … but seriously, that would not be Yii to me anymore.
Your assessment is correct, but look at Yii2 it has remained in time and every new day I see more corrections is amazing as it has resurfaced, and it is simple, Yii2 is a very simple framework that allows you to add any php library and work correctly, for example the way to handle the routing, the templates, the views and to write the code of them in bootstrap not even Laravel has it.
i talk about additional ability to have controllers with multiple actions and more simple arguments and options definition. In some cases symfony commands are good and more right way, but in some cases yii2 way useful too
Yii is a framework, not a system. I think it would be awkward to use pieces from other frameworks.
An acceptable option would be to leave the choice to the developer.
If You want Symfony console, add “this” to your composer.json
If You want Yii 3 console, add “that” to your composer.json
We could start with the Symfony only and slowly improve our own util can make it the default console and Symfony becomes an option.
Multiple action controllers aren’t good idea for console commands considering dependency injection via constructor. Options and argument definitions could be easily ported over. What parts do you think are particularly good?
This depends on specific case. I would say that in most of cases it is completely irrelevant - if your console controllers have sane scope and do not group many completely irrelevant actions, injecting all dependencies in controller constructor should not be a problem. And even if you will get some injected but unused dependencies, you can usually ignore it (console controllers have much lower load than web controllers, so performance impact is negligible).
I would rather try creating wrapper if Symfony Console lacks some features - maintaining a fork of an active package may require more work than creating wrapper or completely new implementation.