Drupal 8 and Composer can be friends

10 years ago (at the end of 2006), Drush appeared to make it easy for Drupal developers to do some common tasks, it wasn’t immediately popular as it was a Command-LIne tool and a lot of people didn’t appreciate the idea, but year after year its popularity grew as did its functionality.

By the time Drupal 7 came out it was unimaginable for most developers to build a site without Drush because of the incredible boost they got in their development process and the option of generating a site from a makefile and avoiding the need to add in their project contrib code or risk of people hacking the behaviour of this module and unfortunately this was a common practice.

But Drush with the makefile wasn’t good enough, if they update some module the makefile won’t show any update, sometimes some releases breaks other modules and it wasn’t a clear way to say “I need up to this version of that module”, indeed the whole update process itself wasn’t very automated at all, and it was only useful for download a specific version of a module and with his dependencies (it gets the latest version of them without check if they are compatible)

In parallel, 5 years ago the PHP community started development of “Composer“, a tool for dependency management of open source PHP libraries. It quickly became very popular, and big frameworks like Symfony adopted Composer the same year it was released (Symfony 2.1.0 was the first version to use it, but nowadays all PHP frameworks use it as default install method). This tool addressed all the dependency issues that Drush had and also implemented Autoloading.

When Drupal 8 come out in 2015 it tried to use Composer in a very non-intrusive way, as a result, Composer was hardly worth using. It was very slow, every new version overrides composers files, and had a few other disadvantages but at least we got autoloading (finally!!). However, things changed once the GitHub project “drupal-composer/drupal-project” appeared, suddenly it was possible to create a Drupal site and add/remove/update modules very easy without the help of any external tools other than Composer.

How Composer works

When you execute ‘composer install’ it first reads the lock file and installs everything from there, if this file doesn’t exist it reads the JSON file and installs the latest version that is specified there and then generates the lock file.

Executing ‘composer update’ ignores the lock file in order to get the latest version of what you specified in the JSON file so it’s a very similar process to when you execute the install without the lock file.

Composer does more things than just download packages, it also provides an autoload for all the namespaces, and you can also define custom namespaces for your project, for example, a namespace for your tests.

You have also the option to add hooks (pre, post, etc..) on the script's commands to further automate your application build process.

Configuring Composer

Repositories

Composer by default uses packagist as a unique source of packages and Drupal is available under “packages.drupal.org/8”. If we have some custom module, profile or theme in another place like GitHub, Bitbucket, your own packagist account or any other private repository we are going to have to add them as a custom repository.

Composer lets you define settings for repositories, such as the type of a repository For more information read this documentation.

Dev mode

By default, Composer uses the dev mode but you can add –no-dev to install only your Production libraries.

Scripts

Config option

Conclusion

It has a very intuitive standard and you can build an amazing easy deployment process, which is easy to understand for other developers and use it in CI/CD tools.

So don’t be afraid of Composer, start using it today and find out for yourself how useful it can be!

Comic Relief Technology

This is where we showcase the ways that we are use…