Use of Composer (instead of Drush Make) for building Drupal site

[jasloe]

Just getting started with Drupal 8 and seeing that quite a few folks are using Composer to build. Any plans to include Composer support as a build option, instead of make?

[geerlingguy]

I would like to do this soon, yes; just waiting for things to standardize a little more. I know there is a more-or-less 'official' workflow now (see below references), but there is still differing opinions on best practices for some of the sticky bits, like versioning, patches, extra libraries (non-PHP), etc. so I'm not sure if this will be a feature by Drupal VM 3.0.0 or not.

References:

• Using Composer in a Drupal project
• Composer template for Drupal projects

The full workflow is currently supported, but not automated by, Drupal VM.

[geerlingguy]

This is also something that I'm considering using as an excuse to switch things to my geerlingguy.drupal role instead of custom playbooks inside Drupal VM.

[ghost]

I noticed this drupal.org issue for direct Composer support that might be worth following:

https://www.drupal.org/node/2551607

[jasloe]

Good news, Jeff. Thanks for such a great resource. Slightly off-topic: wondering whether the addition of Drupal Console is also something worth exploring in the context of this project?

[geerlingguy]

@minorscience - Drupal Console has been part of Drupal VM for some time :) — just make sure it's uncommented in installed_extras.

[oxyc]

@geerlingguy but then it's only a documentation issue right? Would be cool to get the building blocks in for a 3.0.0 release as I assume switching to geerlingguy.drupal would require quite a few breaking changes. Docs for best practice could be added or tuned later in my opinion. I'd like to give composer a shot too as we've made the switch on all of our non-Drupal projects already :)

Edit: or are you considering using composer as the default instead of drush make?

[thom8]

👍 for geerlingguy.drupal - would be good to collaborate if possible.

We're looking to push this role to galaxy when stable, which currently supports composer installations.

[geerlingguy]

I'm considering composer as the default, and drush make as an alternative option. It's definitely going to be the future of Drupal 8 site building, and the main/only reason to keep it around is for D7 projects, imo.

[frob]

+1 to this. Just started finding drupal projects that drush cannot install correctly.

[heddn]

https://github.com/MTechLLC/d8_starter is composer driven base d8 starter site that has ideas to consider.

[fubarhouse]

@geerlingguy drupal console has been fixed for some time - it's used again in the provisioning of the systems I look after, so feel free to throw it out there again!

[heddn]

I've been using a 100% composer driven workflow with drupalvm for the past 3 weeks. I don't know that anything needs to change in the project. Some of the workflow to run a drush make need to be disabled. And a post provision script to run composer install + drush si config_install (I'm using config installer module to install from config stored on the filesystem on up from the webroot.)

[geerlingguy]

@heddn - For Drupal VM's purposes, the main change would be to use a composer.json file instead of the Drush make file to build the baked-in Drupal 8 site. But you're correct, the full workflow is already supported if you're doing a manual/self-scripted site installation.

[oxyc]

@geerlingguy are you thinking about bringing in geerlingguy.drupal for this task or simply switching build_makefile: false and adding composer.json as the default?

[geerlingguy]

@oxyc - Long term I'd like to use geerlingguy.drupal... but that's a heftier project, since I'm trying to do a comprehensive rewrite of that role to make it work for all my production deploys/updates/etc.

So if it's quicker, I'm happy to just changeover things in Drupal VM to support a fully-composer-based-workflow.

[geerlingguy]

Especially if you want to tackle it, and earn yet another free beer if I ever get to meet you :D

[oxyc]

Hold off on 3.1.0 a bit and I'll try to get a PR for tomorrow hopefully. With BLT and d8 in mind it would be nice to default to a composer based install instead.

I've scheduled 2018 for traveling around the US so I'll stop by for a few beers then :D

[thom8]

@oxyc -- here's a starting point -- https://github.com/beetboxvm/beetbox/blob/master/provisioning/ansible/roles/beetbox-drupal/tasks/build-composer.yml

but +1 for a galaxy role that we could share.

[geerlingguy]

@thom8 - That's the end goal, but initial goal I think will be to just keep spreading adoption of composer.json for Drupal 8 site builds. I'm finally using it for a large project now, and besides a few growing pains, it's great!

[thom8]

Drupal 9 might only be a composer.json file 😉

[geerlingguy]

@thom8 - That would be awesome—by that time, I hope our greatest hurdle to adoption will be overcoming the Mars-->Earth latency in composer-based dependency downloads.

[oxyc]

@geerlingguy what do you think about using drupal-composer/drupal-project as another default option?

Would be nice if it worked like:

• If build_makefile is set to true, install with makefile.
• If build_composer and a composer.json exists (as with BLT), install from there.
• Otherwise with build_composer, install drupal-project.

Might be a bit tricky due to the docroot path being different between drupal-project and makefiles. I'll play around a bit.

Other option is to provide an example.composer.json that people need to copy and rename as they do with makefiles at the moment. That's a bit of a maintenance burden though.

[mchelen]

+1 for drupal-composer/drupal-project because it's the cleanest way I've found to manage a drupal codebase with composer

[geerlingguy]

Either way may be workable... I haven't tried drupal-project itself before, just composer.json.

[geerlingguy]

All right, the main supporting code has been merged, and I've opened up a follow-up issue to discuss defaulting to Composer at some point in the future: #699