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-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:
composer.jsonbecomes 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.
composer updatecommand 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 can make the updating of distributions easier, by effectively managing the required dependencies of the entire distribution. E.g.
composer update lightningwould update the Lightning project, including any modules and packages specified in the
composer.jsonfor the Lightning distribution.
Adding new modules to your codebase is a lot easier as it only requires you to use a simple one line
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.jsonfile, it caches all versions that are defined for a particular project. This means that if you had your module version set at
1.1but 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.jsonso 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.jsonfile to avoid them being touched during an update.