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 it’s 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 override the 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

Composer uses a JSON file where you define the setup of your project and a lock file that contains the exact versions of installed packages when you last run composer update, or when this lock file is generated. This file is especially useful to make sure deployed versions of dependencies are the same on every build and deployment. This file is commonly committed into version control.

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 scripts commands to further automate your application build process.

Configuring Composer

Repositories

This is probably one of the most important to understand for Drupal developers.

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

In the JSON file you can define libraries and namespaces that are going to be used only for development, in this way you can deploy minimal code to Production while in your development environments you can have that plus some test frameworks and debugging tools while defining everything in the same file.

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

Scripts

You can create custom commands, which are very useful for things like  providing an alias for very common commands, or running multiple commands with a single command, or aggregating commands before or after execute. You can find more documentation here.

Config option

In config you can add tokens for a private repo, or change the default behavior of Composer, most of them are really useful to avoid having to add parameters when you execute any Composer command. The official documentation of this section can be found here.

Conclusion

Composer is not a replacement for Drush or Drupal Console, but Composer has so many other great benefits that it’s worth persevering with it and adopting it more widely across the Drupal and PHP communities as the base of development workflows.

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!

Also posted in here