I like the idea.
I think this belongs to the framework, not the Console component.
Components should not be aware of bundles, it's the other way around.
FrameworkBundle looks like a perfect fit for this, as it represents the glue for all Symfony components and bundles, and it has its ownconsole Application.

i'd prefer something like we did for twig:https://github.com/symfony/symfony/blob/master/src/Symfony/Bridge/Twig/UndefinedCallableHandler.php

i think its more straightforward to handle it in e.g. a catch-all event listener for unknown commands, opposed to tracking a list on high level (console application).

I had some doubts adding it to the main application, since it is widely used as a standalone component, but I wanted the suggestions to be available for some, who started his project with a symfony/skeleton (so without the FrameworkBundle) and tries to use features, that are not installed.

By the way, can you tell me, why my CI checks failed? Did I forget about something in my PR?

My mistake. I confused FrameworkBundle with SensioFrameworkExtraBundle. I will rework the PR.

But my other question about the CI checks is still valid :)

I went with the suggestion from@ro0NL and created an event subscriber. I can always switch to a try/catch inFrameworkBundle Console Application.

I improved the logic. For example, when someone hasWebServerBundle and runsserver:dump, the message will suggest installingVarDumper (along with alternatives from the originalCommandNotFoundException). But onserver:foo will add nothing - just show the alternatives.

@fabpot Done.

Too many reviews in a short period of time and things got a little messy for a moment. I've implemented all suggestions the code, fixed the tests. The one Travis CI test that fails, failed before and I guess it has nothing to do with my code directly.

The only thing left to decide is whether to putthe back in the exception message by default, or add it to selected messages. I'm in favor ofthe by default.

Thank you@przemyslaw-bogusz.