Composer 2 FAQ

I’ve been using Composer 2 daily for several weeks now (see my previous article on How and Why to Upgrade to Composer 2 if you haven’t done so yet!). In that time, I’ve gotten a lot of questions from folks in the Drupal community about the experience and problems they are facing. Here are a few of the common ones!

Is it really worth updating?

Let’s start with the biggie: is it actually worth the effort to do the update? In a word: yes. Absolutely yes. It is so much faster your head will spin, especially if you (like me) have used composer for several years and you have gotten used to the amount of time certain key tasks (specifically updating dependencies takes). Normally a composer install is “pretty quick” on composer 1 and honest to god, composer updates feel like they are just as fast in composer 2. It’s seriously bonkers how much better it is and you should definitely update for this reason.

Is it backwards compatible with Composer 1?

Yes! I haven’t had any issues on projects where my host is running composer 2 but others on the team (or my CI/CD solution) are still running composer 1.

TLDR: composer 1 stuff is NOT always compatible with composer 2 but as far as I’ve seen everything about composer 2 is backwards compatible with no trouble. Obviously a composer 1 binary isn’t going to get the speed improvements, but that’s the only drawback I’ve encountered so far.

What happens if a particular package on my project isn’t compatible?

This is probably the most common issue that comes up. “I have composer 2 and this thing doesn’t work.” Don’t worry! You aren’t alone. I just saw this question the other day on Drupal slack:

- ocramius/package-versions is locked to version 1.4.2 and an update of this package was not requested.
- ocramius/package-versions 1.4.2 requires composer-plugin-api ^1.0.0 -> found composer-plugin-api[2.0.0] but it does not match the constraint.

While I’m not familiar with this particular library, a quick Google search shows me a release from October 2020 that adds coverage for composer 2: https://github.com/Ocramius/PackageVersions/releases/tag/2.1.0. So in the case here, all that is needed is to update from version 1.4.2 to version 2.1.0+ and this package will no longer throw the above error. Not sure how to do it? Let’s dig into that real quick.

First, you want to check and see if your project composer.json file has a dependency on this or not. If it doesn’t, you can run something like:

composer why ocramius/package-versions

You MIGHT be able to just run a composer update ocramius/package-versions --with-all-dependencies to facilitate the update… but it really depends on how it’s required (which is why I have you checking composer files). If it’s ^ required then it will probably bump up fine. If it’s ~ required or pinned to a specific version, then you either need to update your root composer.json (if you are the ones requiring it) or update the dependency that is itself requiring ocramius/package-versions.

This is much easier than this length of text suggests.

TLDR: if you see an error like the one above just composer update the packages throwing the error and they should go away! If they don’t, then you are trying to use a package that hasn’t been updated to support composer 2 (and you’ll have to deal with that or ask someone else to).

What happens if my CI / CD tool doesn’t support Composer 2 Yet?

This one is also super common. Because composer is a binary that actually gets installed at the container / application level, you may not have the appropriate level of access inside your CI/CD container to update the binary from composer 1 to composer 2. You can pretty quickly find out if you do by scripting:

composer --self-update

If your build updates, cool! If it doesn’t, sad. But it’s really not the end of the world if your CI/CD process continues to use composer 1. Why?

As I said above, personally I’ve seen the biggest speed differences when running updates / requiring new dependencies. The installation of dependencies has always been pretty snappy because the lock file already requires all the needed hashes and dependency calculations. The thing that has always been so so slow about composer is the calculation of the necessary dependencies (and this is a lot of what composer 2 changes). So if your CI/CD pipeline is running composer install and you have your lock file committed (which, I would say is “generally” a best practices — there may be times when you wouldn’t) then a composer install in CI/CD shouldn’t be “significantly” faster with composer 2 than it is with composer 1.

In Conclusion

Like I said at the top… it’s definitely worth the update to composer 2. The very first one I did (which I talked about here) took me a little bit but that was because I really didn’t know what to expect and I was early enough in the lifecycle that a lot of packages I relied on (e.g. BLT) hadn’t yet cut composer 2 stable releases. Now that we are ~2 months past the drop of composer 2, I think most of the biggies are already going to support composer 2 (you just need to do the update and update your packages to take advantage).

Happy composing!

Related Content