With the evolution of Drupal into versions 9 and above, the reliance on third-party libraries has grown, cementing Composer's role as the quintessential tool for managing your Drupal codebase.

We advise against using Drush for updating Drupal 9 or later versions. While Drush remains a useful tool for maintaining Drupal 7 core and select contributed modules, its functionality in newer Drupal versions is limited. It's important to note that Drush 10 and subsequent releases no longer support the pm commands (e.g., drush pm-updatestatus, drush pm-update) that were historically used to update Drupal through Drush.

For Drupal 9 or newer sites, Acquia's Remote Administration service firmly endorses the use of Composer as the optimal method for codebase updates and maintenance. To facilitate this process, we provide a sample composer.json file on Github, which you can clone and tailor to your project's requirements.

So we no longer support Drush updates for Drupal sites using version 9 and beyond. It's strongly recommended to adopt Composer for a streamlined development workflow that ensures compatibility and stability across all components of your Drupal project.

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:

• Dependency Complexities: With Composer 2 handling dependencies for Drupal 9+, while dependencies and sub-dependencies are managed more efficiently, it can still be challenging to pinpoint the cause of an error. It remains crucial during testing and troubleshooting to carefully review the changes to understand the source of any issues.

• Caching Improvements: Composer 2 features significant improvements in the way it handles caching and memory consumption. Unlike its predecessor, it is more efficient in resolving and caching dependencies, reducing the likelihood of memory issues. However, maintaining an up-to-date composer.json file with the precise versions of the packages you use is still best practice and can aid in more predictable updates.

• Handling Customizations: When updating with Composer 2, it’s still true that it will replace the contents of the module and/or core directories with new versions. To safeguard custom modifications or files, they must be explicitly excluded in the composer.json file under the appropriate sections, such as "scripts" or using "patches", to prevent them from being overwritten during updates. Moreover, it’s recommended that customizations be managed through child themes or custom modules to ensure that updates do not lead to the loss of bespoke functionality or design elements.