<p dir="auto">Hi,<br>
some days ago, I wanted to launch a debate about the console commands available in Standard edition.</p>
<h2 dir="auto">Actual status</h2>
<p dir="auto">For the record, we have 72 commands available when we install Symfony (71 if we remove the Symfony ACL component).</p>
<p dir="auto">I don't think this need a screenshot, we can say the first contact with the console is undoubtely disturbing for a lot of newbies:</p>
<ul dir="auto">
<li>too much commands;</li>
<li>too much options</li>
<li>some weird duplicates ... (this point is already fixed in 3.0.X release)</li>
</ul>
<p dir="auto">Before release the new major in november, the deletion of all deprecated command is planned (no specific issue) and the new UI update is in progress (<a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="65463015" data-permission-text="Title is private" data-url="https://github.com/symfony/symfony/issues/14138" data-hovercard-type="issue" data-hovercard-url="/symfony/symfony/issues/14138/hovercard" href="https://github.com/symfony/symfony/issues/14138">#14138</a>).</p>
<p dir="auto">Commands of Standard Edition come from Bundles:</p>
<ul dir="auto">
<li>AsseticBundle</li>
<li>DoctrineBundle</li>
<li>SwiftMailerBundle</li>
<li>FrameworkBundle</li>
<li>...</li>
</ul>
<p dir="auto">They are autoloaded and registered without any intervention of developper. As <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/fabpot/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/fabpot">@fabpot</a> said, if we don't want the commands, we can uninstall the related bundle.</p>
<h2 dir="auto">Commands come from bundles</h2>
<p dir="auto">But theses bundles provide a lot of others useful things that make them required in Standard Edition:</p>
<ul dir="auto">
<li>Compiler passes</li>
<li>Event listeners</li>
<li>Complete applications ? (like the WebProfiler)</li>
</ul>
<p dir="auto">So, I think remove some of theses bundles can't be an option.</p>
<h2 dir="auto">Survey about Symfony commands</h2>
<p dir="auto">Few days ago, I started to share a survey about the Symfony commands use. You can see the <a href="https://fr.surveymonkey.com/results/SM-WWZ7CFL2/" rel="nofollow">complete results here</a></p>
<p dir="auto">Some easy conclusions according to the survey:</p>
<ul dir="auto">
<li>Almost 15 commands are (mostly) never used</li>
<li>60% (~50 !) of theses commands are not used by a majority of developpers</li>
</ul>
<h1 dir="auto">Some ideas</h1>
<p dir="auto">To improve the DX of the Symfony console, many strategies can be applied:</p>
<ul dir="auto">
<li>Remove some commands;</li>
<li>Move theses commands into "Extra" Bundles (debug-command-bundle, security-command-bundle, doctrine-command-bundle ...);</li>
<li>Make some of theses command real console applications (yaml-linter, php-security-checker ...);</li>
<li>Play with the <code class="notranslate">isEnabled()</code> function: only enable to most used command by default;</li>
<li>Implement a "two levels" displaying of console like rails for instance: the first time we only see the categories of commands, then when we call a category (<code class="notranslate">php app/console doctrine</code>) the console returns all available commands in this category.</li>
<li>... and probably far better ideas you have :)</li>
</ul>
<p dir="auto">Of course, many strategies can be applied, and this issue is more about debate than suggest a pull request that remove everything :)</p>
<p dir="auto">What do you think ?</p>
<p dir="auto">I suppose you already had this before as well, copying a route and forgetting to rename it. The old route gets overwritten and you might not even notice it until its too late.</p>
<p dir="auto">How about throwing an Exception when the same route name is defined twice in the same YAML or XML file to increase developer experience?</p>