Composer

Composer is the dependency manager for PHP. A Drupal project lists the packages it needs in a file called composer.json, and Composer downloads them together with the packages they depend on: Drupal core, contributed modules and themes, and libraries such as Drush. It installs everything per project, not on the whole server.

How Composer works in a Drupal project

Three files and folders matter:

• composer.json lists what you ask for. Its require key maps package names to version constraints; require-dev holds tools used only in development.
• composer.lock records the exact versions that Composer picked. Commit it, so every environment gets the same code.
• vendor holds the downloaded third-party code. Composer also writes vendor/autoload.php there, which loads the classes.

Drupal's recommended project template keeps a web directory as the public document root. The vendor directory and the project files stay outside it. Modules and themes from Drupal.org arrive through the Drupal.org Composer endpoint, packages.drupal.org, and the installer-paths setting sends them to the right folders.

Version constraints

A constraint says which versions are acceptable. The caret is the usual choice: ^1.2.3 means at least 1.2.3 and below 2.0.0. The tilde is stricter: ~1.2.3 means at least 1.2.3 and below 1.3.0. Below version 1.0 the caret also narrows, so ^0.3 stays below 0.4.0.

Commands you will use

The require, remove, install and update commands accept --dry-run to preview a change. Install and update also accept --no-dev to skip development packages.

Example: from new site to first update

composer create-project drupal/recommended-project my_site_name
        cd my_site_name
        composer require drush/drush
        composer require drupal/token
        composer update "drupal/core-*" --with-all-dependencies
        vendor/bin/drush updatedb
        vendor/bin/drush cache:rebuild

The first command builds the site from the recommended template and installs its dependencies. The last three are the core update routine from Drupal.org: update the code with Composer, then let Drush apply database updates and rebuild the cache.

Common mistakes

• Mixing manual downloads with Composer. Once Composer manages a module, update core with Composer too. A manual core update replaces vendor and removes libraries that contributed modules need.
• Not committing composer.lock. Without it, two environments can resolve different versions of the same package.
• Lowering minimum-stability for one pre-release module. Ask for that module with a stability flag instead, for example composer require drupal/field_group:^4.1@alpha.
• Running composer update on a production server. Update on a development machine, commit the lock file, and run composer install on the server.
• Ignoring prompts about plugins. Composer plugins run code, and the allow-plugins setting lists which ones may run. In non-interactive mode, a plugin that is not listed makes Composer fail.

For marketing and content teams

When a developer says a module or theme "needs a Composer update", they mean the code behind your site is being changed. Because the lock file records exact versions, a module that works on staging will run the same version on production. Ask for the update to be tested on a staging copy first, especially for security updates that you want live quickly.

With DXPR

DXPR Builder is on Drupal.org and installs the usual way: composer require drupal/dxpr_builder. Its page also lists versioned commands for pre-release builds. See DXPR Builder for what it adds to your editing screens.

Sources

• Composer: Introduction
• Composer: Basic usage
• Composer: Command-line interface
• Composer: Versions and constraints
• Composer: The composer.json schema
• Composer: Plugins
• Drupal.org: Using Composer to install Drupal and manage dependencies
• Drupal.org: Updating Drupal core via Composer
• Drupal.org: DXPR Builder project page