Move drupal/console from a required dependency to a dev dependency

[pfrenssen]

Drupal Console has some nice functionality but it is not strictly required for drupal-project to function.

I would propose to move it from the require section to the suggest section. This means that when a Drupal project is created or updated, Composer will output a suggestion to install Drupal Console, and developers can then decide whether to use it or not depending on the needs of their project.

[jackbravo]

But the same would apply to drush right? Neither are actually needed for creating a drupal site, but people use them extensively in development. Since this is a starting point primarily for developers I like that both are enabled.

[FatherShawn]

And I noted that we should treat them similarly on the PR at #353 (comment)

[derhasi]

I personally see drupal/console still as a best-practice to use in a drupal development setting. As this project should be a collection of best-practices I would not strip that away. For me Drupal Console and Drush are a crucial part of Drupal development, especially when you are used to go with the CLI and therefore they should be there out of the box in my opionion.

[g3r4]

I mean, if you are a professional developer that does not like to waste time, I would say it is required. I don't see the harm in including it, only benefits.
Also, Symfony comes with Symfony console as part of the project, Why shouldn't Drupal come with something similar (but more powerful)?

[eliasdelatorre]

For the sake of consistency, both Drush and Console need to be moved to "suggestions", since none of them are strictly required for a Drupal installation.

I can see why Drush may be set as a required dependency but, frankly, the same applies to Console. Since the D8 workflow is much more complex, there's a need to have enough tools to make the initial development doable.

If this issue is about strict syntax and low level discussions, then ok, let's remove it, but we need to do the same for everything else that is not required, just like Drush.

Personally I feel that both are required if you want to do any actual work with D8.

[nicolas-grekas]

This doesn't provide the same experience at all.
drupal-console is a requirement to the experience the authors of drupal-composer want to provide out of the box. Thus it belongs to "require". I understand that you have a different definition of what "require" means, but there is nothing anywhere that makes your definition more accurate than this definition given here: a requirement to the experience. That's a great thing.

[allgood2386]

The use case for having both tools installed by default is a far saner default then catering to the limited use case where you can't have it (presumably for infra/ATO/FEDRAMP compliance type deals).

I'd argue as a project which is providing a default code base to work from it makes sense to keep both projects in the required section. If someone needs to remove them it should be 2 trivial composer commands.

That all being said, if it is moved, both tools should be treated equally.

[pfrenssen]

Everybody seems to be missing the point a bit here. Composer is a dependency management tool with very well defined sections. I'm not advocating to remove drupal-console, but to move it to the right section. Currently it is in require which is not correct, because a Drupal project does not require it to function in production. require is the section that declares the dependencies for production.

@jackbravo

Neither are actually needed for creating a drupal site, but people use them extensively in development. Since this is a starting point primarily for developers I like that both are enabled.

@derhasi

I personally see drupal/console still as a best-practice to use in a drupal development setting. As this project should be a collection of best-practices I would not strip that away. For me Drupal Console and Drush are a crucial part of Drupal development, especially when you are used to go with the CLI and therefore they should be there out of the box in my opionion.

@eliasdelatorre

I can see why Drush may be set as a required dependency but, frankly, the same applies to Console. Since the D8 workflow is much more complex, there's a need to have enough tools to make the initial development doable.

What all of you have in common is a need is to have drupal-console on a development environment, so that you can create a drupal site and develop it: then require-dev is the place to be. Not require which is the production build.

I wanted to add it to suggest so people can decide for themselves where to put it. But require-dev is also fine for me. I personally use drupal-console for initial scaffolding at the start of the project, and after this phase I don't need it to be permanently available in my development environment. But it seems most people here think it is worthwhile to have it permanently on their dev machines.

[pfrenssen]

@eliasdelatorre

For the sake of consistency, both Drush and Console need to be moved to "suggestions", since none of them are strictly required for a Drupal installation.

We cannot move Drush to suggest since it is an actual dependency of drupal-project itself, we use it in the test suite. I proposed on the PR to move it to require-dev but @weitzman made the correct observation that a typical Drupal site requires it in the production environment.

[jmolivas]

@pfrenssen We used and have clients using DrupalConsole on production servers and also using it on their CI/CD workflow.

All this is because:

• DrupalConsole provides commands for debugging and maintaining Drupal sites not only generators.
• DrupalConsole provides chains commands to automate pipelines used on CI/CD workflow.
• DrupalConsole provides site alias for remote command execution.

Making a change like this will affect people using DrupalConsole via DrupalComposer on prod sites for
daily site maintenance and debugging.

[pfrenssen]

@jmolivas yes but you are the maintainer, you are a special snowflake :) I think 80% of Drupal sites do not require it in production.

It is a heavy package with many dependencies. For maintenance reasons the production builds should be as small as possible.