Using Composer with Drupal 8/9 and Remote Administration

As Drupal sites and contributed modules become increasingly reliant on third-party libraries to work correctly, Composer is becoming the best way to manage your codebase effectively.

We do not recommend to use drush to update Drupal 8 or above. Drush remains a valid means of maintaining a Drupal 7 core and some contributed modules for the time being. However, there are significant changes coming down the pipe in Drush 9 which will remove the pm commands (e.g. drush pm-updatestatus, drush pm-update) used to perform updates via Drush.

Acquia’s Remote Administration service strongly recommends Composer as the preferred approach for updating Drupal 8 sites. We provide an example composer.json file on Github that can be cloned and modified as a starting point.

While you can still use Drush updates for Drupal 8 sites, this can introduce issues if dependencies are not installed and/or updated. We do not provide Drush updates for Drupal 8 sites.

Advantages of using Composer

Switching to Composer takes some initial setup, and will take some getting used to if you are unfamiliar with how it works. Once a valid composer.json file is in place and you have a basic understanding of how it works, there are a number of advantages to using Composer:

• The composer.json becomes a blueprint for your codebase, enabling it to be easily installed in a new location and pulling in all the required projects and their dependencies.

• The composer update command allows you to easily update all or specific packages quickly without needing to manually download new packages and install them or use patches.

• Composer allows you to easily lock down modules to a specific version within the composer.json.

• Composer can make the updating of distributions easier, by effectively managing the required dependencies of the entire distribution. E.g. composer update lightning would update the Lightning project, including any modules and packages specified in the composer.json for the Lightning distribution.

• Adding new modules to your codebase is a lot easier as it only requires you to use a simple one line composer require command.

An increasing number of contributed modules are built using Composer, and have their own specific dependencies which are required when adding them to your codebase. Without Composer, you would need to manually install and update these every time you installed or updated a module.

What to be aware of when using Composer

While Composer is a great way to manage your site, there are some additional points to also be aware of that may catch you by surprise:

• Because Composer pulls in dependencies, and sometimes dependencies of dependencies, if an update causes problems it can sometimes be more difficult to establish the cause of an error during testing and troubleshooting.

• When Composer checks your composer.json file, it caches all versions that are defined for a particular project. This means that if you had your module version set at 1.1 but you were looking to update to 1.5, Composer will cache all versions in between. This can lead to memory exhaustion issues so it’s a good practice to regularly revise your composer.json so that the versioning is more in-line with what you actually have installed. (This problem has resolved in the Composer 2.0)

• Composer’s method for updating is to replace the entire contents of the module and/or core directories. This means that if you have any custom or modified files, these should be defined in your composer.json file to avoid them being touched during an update.