Security in Code Deployment – part 4: Advantages of using Composer
Code examples for this article: https://github.com/rpsu/dwd-security-in-code-deployment
This is part of “Security in Code Deployment” -series.
- Security in Code Deployment – part 1: Drush make file
- Security in Code Deployment – part 2: Patch modules with Drush
- Security in Code Deployment – part 3: Unknown Drupal codebase
You are most probably familiar with Composer, at least on a conceptual level. It is a dependency manager with all of the functionality of Drush, and more. From the perspective of building the codebase, the difference between Drush and Composer is the recipe file format and the use or Composer, not Drush, as the build tool. Drush and Composer are not mutually exclusive, you can use both; you can even install Drush along with Drupal using Composer.
Composer uses JSON files, which use curly brackets instead of indentation, as in YAML files. However, unlike Drush make files,
composer.json files are not meant to be edited in quite the same way. Composer keeps the
composer.lock files up-to-date according to your instructions. You still need to add some things manually to
composer.json, such as the patches you want to use in modules.
From a code deployment perspective, using Composer is just a better way to manage all required resources, because it also makes sure all the module requirements are met; you could learn the hard way that something is missing with the use of an (incomplete) Drush make file.
$ composer create-project drupal-composer/drupal-project:8.x-dev drupal.local
--stability dev --no-interaction
$ cd drupal.local
Composer can be used with Drupal 7 projects, too. All you have to change is the branch name in the command to
7.x-dev. Now the
composer.lock files have been created. The Drupal root (the
index.php file) is in the
web folder, as are other Drupal modules and themes. Other resources (dependencies) are in the
vendor folder. You might take a look at what is in the folders; just remember that
composer.lock contains the whole dependency tree, which easily makes it quite long when compared with the
Start by adding Drupal.org as one of the package (module) sources; then, start adding your project dependencies. In Listing 13, I’m adding the very latest version of the Token module that is compatible with the defined Drupal core, as well as a specific version of the Field Group module and a specific commit (1fe3649) from Ctools module’s 8.x-3.x branch. Composer will update
composer.lock files when you add (or remove) dependencies.
LISTING 13: Add Modules with Composer
# Configure Drupal.org as a package source
$ composer config repositories.drupal composer https://packages.drupal.org/8
# Add some modules
$ composer require drupal/token
$ composer require drupal/field_group:1.0-rc4
$ composer require drupal/ctools:dev-3.x#1fe3649
Once you have committed and pushed changes, your colleagues can get exactly the same codebase every time, with all dependencies included. All they have to do is clone your repository and run:
$ composer install --prefer-dist --optimize-autoloader