Drupal Composer

Composer can be used to manage Drupal and all dependencies (modules, themes, libraries). Make sure you have composer installed on your local machine before executing any Composer commands. Download Drupal core using Composer.

  1. Drupal Composer 2
  2. Drupal Composer Update
  3. Drupal Composer Manager
  4. Drupal Composer Patches

Discussions
in Drupal Group

On groups.drupal.org/composer general communication takes place. It is good starting point for checking out the current progress.

Composer

Packages
on drupal.org

  1. Recommendation note: Use defaults (skip config above) if possible - this package will be maintained throughout the Drupal's lifecycle in order to optimize legacy constraints in parallel with Drupal's requirements. All you have to do is to make sure your drupal core constraint in the root composer.json is set to drupal/core: ^8.5 or above. If you use a Drupal distribution, be sure to explicitly.
  2. After Composer updates successfully, push the code back to Pantheon via Git or SFTP. Note that composer update is based on the values specified in composer.json. So, for example, if composer.json specifies drupal/core at ^8 then Composer will update Drupal core to the latest version of 8.
  3. A best practice to create a brand new Drupal application using Composer is to start from a template. Composer's create - project command is intended to do exactly that. When you execute composer create - project some / project, it will clone some / project and use it as a template for your new project.
  4. Note: If you are using Composer 2: Wrong Drupal 7 structure in sites folder with Composer 2. Which doesn't make sense! Is there something missing between those two lines?

The former Drupal Packagist has deprecated. It is now replaced by the official composer repository packages.drupal.org

Source Code
on Github

We are hosting the source code for Drupal Packagist and some other components on github.com/drupal-composer. Feel free to join the projects, file issues and send pull requests.

Getting Started

For a kickstart in setting up a composer based Drupal project, have a look at drupal-composer/drupal-project on github.

Drupal Projects

There are already some drupal projects available dealing with different aspects of Composer in 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 will replace its version with the new shiny Composer 2 release.

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

Is everything ok? Amazing! Continue using Composer 2. Did something go wrong? Downgrade to Composer 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:

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:

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.

Drupal Composer 2

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 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

Drupal Composer Update

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.

Drupal Composer Manager

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

Drupal Composer Patches

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.