Composer vs. Drush Make: Which Should You Use?

If you are not familiar with Composer yet, see the Composer Tools and Frameworks for Drupal presentation that Doug Dobrzyncski and I did for DrupalCon LA. It’s easy to get started quickly with Composer today with starter projects such as example-drupal7-circle-composer and example-drupal7-travis-composer—but is Composer right for your project? Let’s examine some of its strengths and weaknesses:

Recursive Dependency Management

Composer is, first and foremost, a dependency manager. Each dependency that a project requires can itself declare what its dependencies are; if multiple libraries require the same thing, but specify different sets of versions that they work with, Composer will analyze the whole dependency tree and either pick a compatible version, or explain which components do not work together. While Drush Make does allow for recursive make files, no analysis of the dependency tree is done.

Composer’s dependency manager is a point in favor of Composer for projects that need to make use of php libraries outside of the Drupal ecosystem of modules and themes. 

Generation of the Autoload File

One of the best features of Composer is the autoload.php file that it creates during every install or update operation. The autoload function allows php code to instantiate instances of classes without having to know where the source code for each class is located. Autoloading is a built-in feature of php, and is available to Drush Make users through the xautoload module; with Composer, it’s built in, and covers code that is not part of any Drupal module.

Composer’s handling of the autoload file is a benefit for projects that want to use object-oriented php code.

Recording the Exact Components Used in a Build

Composer has a file called composer.lock that records the exact version of each component that was selected in the most recent build. The components listed in the composer.json file can either be locked to a single version, or can be allowed to be updated when new versions are available. With Drush Make, in order to capture the exact version of each component used in the bulid, you must specify the exact version to use in the make file itself. What people usually do to update a make file is use drush pm-update, which itself has a locking function, if it is needed. 

Update: Drush 7 added a feature to Drush Make that allows you to generate a locked makefile, with all versions resolved. With this feature, you need to generate your lock file as the first step, whenever you want to update your dependencies; thereafter, you simply build with the lock file as the source makefile instead of the original file.

So, Make has feature parity with Composer for this function, as long as you are aware of the correct workflow to use with Make. With Composer, the default behavior is to only update when specifically instructed, whereas Make will update every time unless you explicitly use the lock file feature.

Patching and External Libraries

Composer’s support for patching and external libraries are provided by plugins, whereas this is standard functionality in Drush Make. Composer supports patch files via cweagans/composer-patches; see my previous blog post, Patching and the Composer Workflow for more information on this custom installer. It works better, and has a much more compact representation of the patch file list than the previous alternatives. Javascript libraries such as ckeditor can be managed with Composer using generalredneck/drupal-libraries-installer-plugin.

Composer has feature parity with Drush Make for patching and external library use, but you have to know which plugins to use.

Maturity

The biggest advantage that Drush Make has is its maturity. Since it has been in use for so long, and is based directly on the releases repository maintained on drupal.org, and is itself used in the drupal.org profile packaging system on drupal.org, you won’t need to think twice about the availability of and module that you want to use. Composer users have packagist.drupal-composer.org at their disposal, which contains Composer packages for all drupal.org projects with tagged releases. Minor road-bumps may be encountered here and there; some projects might not exist yet on drupal.org or packagist.drupal.org, or a Drush extension might be mis-labeled as a Drupal module in packagist.drupal-composer.org. These sorts of problems are resolvable, but might cause a little extra head-scratching for new users. As Composer adoption increases, these situations will be found, reported and fixed at a greater rate.

Drush Make is more mature than Composer, but Composer is still very usable today.

Score Card

So, which one should you use? It is going to depend on which factors are most important to your project. 

Both are powerful tools that have all of the capabilities needed to get the job done; Composer is stronger in the area of modern features, while Drush Make currently has the most mindshare among projects within the Drupal ecosystem.

Conclusion

Drush Make has served a lot of projects well for a long time, and there certainly is no need to switch maintenance projects over to Composer. Composer is a mature and standard tool in the broader php community, though, and the Drupal community would be well served by adopting it as well over time. Composer has achieved feature parity with Drush Make, and is more modern, more standard, and more convenient. Projects that are under active development using object-oriented code or external php libraries would be well served by a switch to composer today.