Install the devel module as an optional development dependency

[pfrenssen]

The Devel module is only needed when developing, it is not needed in production.

If we put it in require-dev instead of in require we can do a production build with composer install --no-dev that will exclude the Devel module. This also demonstrates this best practice.

[yched]

Note that the question of dev modules is an interesting (and AFAIK still unresolved) challenge for D8 : namely, how do we commit and deploy config changes from dev to prod, yet ensure dev modules are enabled only on dev and not on prod ? - since the list of enabled modules is in one of the CMI files being deployed...

Been discussed in a drush PR by @greg-1-anderson : drush-ops/drush#1430, but is stalled for now. Not fully sure the solution should live in drush.

Meanwhile, I'm not sure what should be our recommended practice about modules and require-dev...

[greg-1-anderson]

I don't like putting devel in require-dev; I put behat and my test tools in require-dev, and there are places where I am compelled to install --no-dev (due to missing components that I don't want to install at the moment), but I still want the devel module available (e.g. on my stage server, sometimes). For my use-case, I am fine with using the database / config system to control whether it is actually available.

However, that's just an example, and just one data point. I think that the point here is that what does and does not go into require-dev is going to be a highly personal decision. Folks can move things around to best suit their particular use cases.

With that in mind, I'm fine with putting 'devel' in require-dev, which is its best theoretical location.

[pfrenssen]

Thanks for the insights. I guess it would be best to postpone this until we have a mechanism to override the list of enabled modules when exporting config, either in Drush or in core. I'm following drush-ops/drush#1430 now.

[greg-1-anderson]

drush-ops/drush#1430 has been merged into Drush core, but I don't know that it fully answers the questions here. This PR only has a way of "excluding" certain modules from consideration when importing / exporting configuration. So, if you have your devel module enabled in your dev machine, but not in your live server, then you can move configuration from live to dev without causing the dev module to be disabled when the config-import command is executed.

This does not explain how the devel module got enabled in the first place, though; presumably, someone did that manually at some point.

The other question is, what would happen if you put devel in 'require-dev', and you then tried to move your configuration from dev to live without excluding the devel module via drush-ops/drush#1430? I haven't tried this experiment, but it probably causes the config-import to fail.

In short, I think more work is needed in this area; putting modules in the require-dev section might cause folks to run into some of these edge cases.

[webflo]

We removed devel from the composer.json altogether a while ago. I ran into problem with drupal modules as dev dependencies. I think we should not advocate it in this template. Feel free to reopen if you disagree.