Cons and pros of using Symfony Console

I was checking existing console implementations this week. Below I’ll try to sum up pros and cons of using Symfony Console vs creating our own.

Our own implementation

  • Simpler. Not that much simpler but still simpler.
  • Can control the code.
  • Uses type-hints in interfaces.
  • Will take time before it’s perfected.

Symfony Console

  • No need to implement it.
  • Doesn’t have too many dependencies.
  • Is OK to work with from my experience.
  • Can focus on actual commands.

What way would you prefer?

  • Our own implementation
  • Symfony Console

0 voters

If you know any additional cons and pros, please voice them.

1 Like

I would like to add a bunch of pros to the Symfony Console:

  • It’s battle-tested and compatible with the majority of terminal emulators
  • Little worries about maintenance, bug fixes etc
  • You benefit from bug fixes and new features without putting effort in it
  • Possible fixes or features added from this community can also benefit other projects using the Symfony console (such as composer for example!)

It is not clear for me, about way of symfony console usage. Should it be as pure integration, or wrapped with yii console controller with actions?

Would wrapping it with controller and actions improve it?

My question is not about improvement, just about ability to keep habitual “yii2 way” of usage.


Just one comment on “Will take time before it’s perfected”…

…maybe, but I think the starting point (yii2 console) is stable enough and to perfect it I think there will be time.

Besides that I always prefer to be able to control the code

1 Like

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.

Is that with Yii3, Yii2 mode will no longer exist, are two completely different frameworks.

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 :slight_smile:


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.


Here’s how yii serve command would look like if using Symfony Console:

1 Like

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.

1 Like

The thing is that console component is one of the least complicated from Symfony ones.

I’ve tried implementing console myself and found out that despite it being a bit simpler, it was quite similar in design.

1 Like

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?

Yes, that could be a good option. I’ll definitely explore it.

There seems to be another option that I was never taking seriously. Forking and adjusting.

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.