Composer 2 and Drupal

Composer 2.0 was released 4 months ago. I don't want to repeat the improvements announced in the release post (check them! They are really interesting), but one stands out among all: the performance.

^{Source: blog.packagist.com by Jordi Boggiano}

Ok, this probably caught your eye. You want to start using Composer 2.0. But software upgrades are never free, there's always some pain waiting to jump over you. While this is true on many occasions, it seems this time is not. As stated in the release post, Composer 2.0 still supports PHP 5.3 and above, like Composer 1. No issues with the PHP version. Good. composer.lock files are interoperable between versions. This means you can use the same composer.json with Composer 1 and Composer 2. You can try Composer 2 and if anything goes wrong just roll back to Composer 1, your composer.json won't' be hurt during the process. What about new syntax? New commands, removed commands? Good question, but no worries: most commands and arguments are exactly the same.

For a detailed description of all the changes of Composer 2, I recommend this article from PHP.Watch: "Composer 2: What's new and changed"

And how to start using Composer 2? It depends on how you installed Composer, but if the Composer executable is under your control (aka you have the permissions to modify it) you only have to run:

composer selfupdate --2

Composer will replace its version with the new shiny Composer 2 release.

Once done, you can try Composer 2 with one of your projects:

composer update --dry-run

Is everything ok? Amazing! Continue using Composer 2. Did something go wrong? Downgrade to Composer 1:

composer selfupdate --1

Honestly, there's a point where issues may arise: the Composer plugins. Because Composer has changed internally a little bit, previous plugins may fail when used with Composer 2. Luckily, the time has passed and many plugins have been updated to work with Composer 2.

Drupal and Composer 2

Drupal loves Composer. And Drupal Community loves Composer too. That's why some smart people were working to make sure Drupal works seamlessly with Composer 2.  The main task was to update the required Composer plugins so they work with Composer 2. The task was completed even before Composer 2 was officially released (the change record is dated almost two weeks before Composer 2).

But, what is the actual experience using Composer 2 on real projects? Pretty good, actually. As said before, Composer plugins can be an issue. However, the Drupal Community provides a documentation page for the transition to Composer 2 where you can see all the plugins that need to be updated to work with Composer 2, the plugins that are not needed anymore (like the previously essential Prestissimo plugin) and the plugins they need work to be compatible with Composer 2. For the development environment, we use a custom boilerplate that provides a complete working Drupal site: Docker containers ready to run drupal (thanks to  Docker4Drupal), MkDocs to document the project, Behat ready to be used, automatic code checking and some other tools. Because Docker4Drupal already provides images with Composer 2, we only had to update the Docker images. Easy!

Composer 2 also provides a command to check the platform requirements that also checks plugins:

composer check-platform-reqs

Also, it is interesting to note a change in how Composer 2 deals with repositories. With Composer v2, Composer will look for packages in all repositories configured in the composer.json file in the order they are set. If a package is found in a repository, Composer will not look for that package in any other repositories further down the line. This is slightly different from how Composer 1 behaves and can produce different results. If this is your case, just check the repositories property in the composer.json file.

By the way, Composer, 1 and 2, always have been very secure when it comes to handling repositories. A month ago, the article "Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies"  by Alex Birsan explained how he used package managers like npm (Javascript), pip (Python), and gems (Ruby) to install malicious code on those companies. It is pretty interesting. And what about Composer? It is not affected, as Nils Adermann explains in this article: "Preventing Dependency Confusion in PHP with Composer".

Some performance insights

Let's do some simplistic tests. I've collected the most installed Drupal modules from Drupal.org. I'm going to set up a Drupal project and require those 100 modules. 

The commands are the same for both Composer versions:

composer create-project drupal/recommended-project test-site
cd test-site
composer config minimum-stability dev
composer clear-cache
composer requiere --profile drupal/token drupal/ctools drupal/admin_toolbar drupal/pathauto drupal/metatag drupal/entity_reference_revisions drupal/redirect drupal/paragraphs drupal/field_group drupal/simple_sitemap drupal/inline_entity_form drupal/entity_browser drupal/search_api drupal/twig_tweak drupal/mailsystem drupal/config_filter drupal/address drupal/entity drupal/embed drupal/crop drupal/video_embed_field drupal/imce drupal/views_infinite_scroll drupal/google_analytics drupal/webform drupal/jquery_ui drupal/editor_advanced_link drupal/better_exposed_filters drupal/dropzonejs drupal/config_update drupal/eu_cookie_compliance drupal/colorbox drupal/block_class drupal/diff drupal/entity_embed drupal/extlink drupal/focal_point drupal/xmlsitemap drupal/ds drupal/views_bulk_operations drupal/easy_breadcrumb drupal/adminimal_admin_toolbar drupal/scheduler drupal/menu_link_attributes drupal/blazy drupal/smtp drupal/link_attributes drupal/config_split:^2.0 drupal/migrate_tools drupal/menu_block drupal/fontawesome drupal/svg_image drupal/swiftmailer drupal/smart_trim drupal/page_manager drupal/rabbit_hole drupal/key drupal/allowed_formats drupal/profile drupal/devel drupal/block_field drupal/robotstxt drupal/facets drupal/file_mdm drupal/password_policy drupal/autologout drupal/color_field drupal/memcache drupal/acquia_connector drupal/recaptcha drupal/restui drupal/anchor_link drupal/token_filter drupal/geofield drupal/views_bootstrap drupal/linkit:^6.0.0 drupal/views_data_export drupal/real_aes drupal/viewsreference drupal/entity_clone drupal/jquery_ui_datepicker drupal/username_enumeration_prevention drupal/encrypt drupal/contact_storage drupal/file_browser drupal/panels drupal/csp drupal/commerce drupal/feeds drupal/chosen drupal/default_content drupal/conditional_fields drupal/image_widget_crop drupal/entity_usage drupal/views_slideshow drupal/redis drupal/advagg

As you see, I set the minimum stability to "dev" and added a version string for the module LinkIt and Config Split. If not, a dependency problem arises. However, it is the same for both Composer versions, both deal with the same set of rules. Also, the Composer cache is cleared to make sure there's no speed up due to cached data.

The results

The first step is to download Drupal using Composer:

The second  step, the heavy one, is to require the 100 most installed modules:

Impressive! In both cases, Composer 2 is about 10 times faster than Composer 1, and the memory consumption drops dramatically. Yes, installing 100 modules in one shot is not something you would do every day, but when you need it you'll be happy to need just 40 MB instead of almost 2 Gigabytes of available memory.

You may argue that one test is not enough and I would agree, but seeing such a huge difference I think there's no need to know the exactly insane percentage of improvement Composer 2 offers.

More results

Let's say we are not going to use Redis, so let's remove the Redis module:

composer clear-cache
composer remove --profile drupal/redis

Composer 2 requires 100 times less memory and it is almost 400 times faster when removing a library than Composer 1! At this point, I guess there's no need for more tests: Composer 2 is incredible better doing its job than Composer 1.

A real example

We have another impressive proof, in this case from a real-life example. We maintain many different projects and this means we have to keep a lot of Drupal site up to date. Manually checking all the sites is not an option. So we have a nice Jenkins job that happily checks projects when we sleep. We focus on stuff that matters and the machine has fun moving and testing millions of bits. A good deal. The job detects all available updates using Composer and then updates one library, commits it and goes for the next. Once this is done, it runs the test suite. The next morning we have Jenkins telling us if we can safely upgrade. This is great, but unfortunately, the jobs were very slow. Until Composer 2 came to us.

This graph shows the time need by the job to complete all tasks. Do you spot when we started using Composer 2 on that project? I bet I don't need to add a red arrow pointing it.

Conclusion

It is simple: start using Composer 2 as soon as possible. Composer 1  is extremely slow, that's the truth, and Composer 2 is extremely fast.

Make this cartoon obsolete, unless you still want an excuse for a coffee break.

Corollary

The impostor syndrome is a thing, in the Drupal Community as well as many other communities. Nobody is perfect and it is easy to spot our own mistakes and think we are not good enough. But I don't want to talk about this because there are a lot of excellent talks and articles about this topic. I just want to point out this: Composer 1 was a good piece of software and it took the PHP world by storm by its dependency management. However, seeing the incredible improvement of version 2, don't you think it could have been much better in the first place? Sure, it could, but even with such flaws, it was a great software and worth it. Remember this when you judge yourself and your work too harshly.