Skip to main content
Drupal composer

Package and dependency management has always been a pain in pre drupal 8 versions. Composer - preferred dependency management library for PHP applications has brought found elsewhere factor to standardization.

It’s quite simple - just list the project name and composer will automatically download and install the packages using a single command.

Installing a new package

composer require drupal/pathauto

The command above will download and install the pathauto module for Drupal. As we all know, pathauto module has a strict dependency on two other contributed modules ctools and token.

Execution of that command alters the composer.json in this way

    "require": {
        "drupal/pathauto": "8.x.x"

Similarly it alters the composer.lock with little more specifications

            "name": "drupal/pathauto",
            "version": "x.x.x",
            "source": {
                "type": "git",
                "url": "",
                "reference": "x.x.x"
            "dist": {
                "type": "zip",
                "url": "",
                "reference": "8.x-x.x",
                "shasum": "xxxxxxx"
            "require": {
                "drupal/core": "^8.3",
                "drupal/ctools": "*",
                "drupal/token": "*"

Though it’s a single line in composer.json, any new package installation through composer.json rebuilds the composer.lock with all the dependencies.

Executing composer install and composer update

When we fire composer update, it executes composer.json and hence our application may get the latest updated packages as specified through wildcards in the package require command. This helps in a way to get the most updated package.

When we fire composer install, it executes composer.lock and hence our application gets all the dependencies as set in composer.lock. This helps in ways to get the dependencies uniformed on multiple environments because it applies the lock on the package versions.

Should we include composer.lock in version control or just ignore it?

There could be both valid use cases.

This is what widely used strategy for composer.json

  • Don't add it to .gitignore so it gets versioned in the git
  • Always prefer to run the composer install on the server as it will ensure to install the fully tested package versions.
  • Executing composer.lock will leave no room for seeing any surprises due to the sudden updated versions of the packages.
2 minutes