How (and Why) to Update to Composer 2

Note: this post was updated on November 16th given that Composer 2 is out and stable (and it was not originally at the time of publication).

Composer is awesome. I’ve written about it a lot on the blog. But, if recent traffic to my site is any indication folks continue to have performance and memory issues with Composer 1.x. So this seems like a great time to chat about Composer 2.x which, primarily introduces massive performance fixes!

What is So Special About Composer 2.x?

If I could distill it down to a single word: speed.

php.watch wrote an article back in April that shows some benchmarks for downloading Laravel using Composer 2 and Composer 1. The results are bonkers:

https://php.watch/articles/composer-2

Composer 2 is more than double the speed of Composer 1 in this example (when there isn’t a cache). I can speak from first hand experience sine starting the update myself. it is noticeable. Really, noticeably faster.

How do you Upgrade?

First of all, at the time of this writing, I want to give a big disclaimer that Composer 2 is still in a release candidate stage meaning it’s not “fully” stable and released. So, you know, your miles may vary.

Updating comes in two stages:

1. updating composer

2. testing / updating your projects

Updating to Composer 2.x

Updating Composer itself is super simple! Just run: composer self-update.

composer self-update
Updating to version 2.0.7.
   Downloading (100%)         
Use composer self-update --rollback to return to version 1.10.0

Note that this also gives you the command to roll back to 1.x (which you may need).

Testing / Updating Your Projects

This is the thing that is going to take a bit longer. Each project will have its own dependencies and each of those dependencies may (or may not) support Composer 2. Here’s an example of what I saw initially on GovCon.

The "dealerdirect/phpcodesniffer-composer-installer" plugin was skipped because it requires a Plugin API version ("^1.0") that does not match your Composer installation ("2.0.0"). You may need to run composer update with the "--no-plugins" option.
The "oomphinc/composer-installers-extender" plugin was skipped because it requires a Plugin API version ("^1.0") that does not match your Composer installation ("2.0.0"). You may need to run composer update with the "--no-plugins" option.
The "acquia/blt-phpcs" plugin was skipped because it requires a Plugin API version ("^1.1") that does not match your Composer installation ("2.0.0"). You may need to run composer update with the "--no-plugins" option.
The "hirak/prestissimo" plugin was skipped because it requires a Plugin API version ("^1.0.0") that does not match your Composer installation ("2.0.0"). You may need to run composer update with the "--no-plugins" option.
The "zaporylie/composer-drupal-optimizations" plugin was skipped because it requires a Plugin API version ("^1.1") that does not match your Composer installation ("2.0.0"). You may need to run composer update with the "--no-plugins" option.

In the case of hirak/prestissim and zaporylie/composer-drupal-optimizations these are both globally installed (for me, they could be locally installed for you) and they aren’t “really” needed for Composer 2. More, Composer 2 actually ignores them! So you don’t need to do anything with these.

A bit of research confirmed for me that both dealerdirect/phpcodesniffer-composer-installer and oomphinc/composer-installers-extender have composer 2 compatible releases (I just didn’t have them locally). More on this in a moment.

Finally, acquia/blt-phpcs did NOT have a Composer 2 compatible composer.json file but it does now (because I fixed it and made it Composer 2 compatible and Dane Powell merged it for me).

So! that puts me in the situation on GovCon of having 3 packages that are “problematic” in my local and just needing to be updated. So I ran a few quick commands:

rm -rf vendor

rm composer.lock

composer update 

And the result was that all of my dependencies updated to run on Composer 2 without further issue. You can see the PR for this here.

Updating Plugins

Some other projects (like BLT) that are more “plugins” or “packages” themselves, there are a few other things that need to be done.

Here’s a couple of examples of PRs I put in to fix these:

• acquia/blt-phpcs

• grasmash/drupal-security-warning

In both cases, it is a matter of updating to support some different packages (note that we are piping these with || so that people can still run Composer 1.x if needed) and adding a couple of new Composer Plugin methods. This is better documented on the Composer docs.

In Conclusion

Composer 2 might not be “quite” ready for prime time yet. But it’s really close. And it’s so good and so fast that you should definitely try it out. You can install the binaries in such a way that you continue to support both Composer 1 and Composer 2 locally if necessary! But it’s not too early to start testing the upgrade and I think you will be very excited to see the results.

A big shoutout and thank you to my colleague Gábor Hojtsy who wrote about this in early September over on his blog. That post was a big help and finally motivated me to do this updated myself.

Related Content