Last updated on
8 May 2017


By default, Composer uses to discover packages. is a repository of metadata about PHP and PHP-related projects. 

Drupal projects are not listed on Packagist. Instead, provides its own repository of composer metadata for Drupal projects.


To learn how you can use Composer (and Packagist) see Using Composer to manage Drupal site dependencies. For configuration in particular, see Define as the source of drupal packages

Converting your project from to the official service

If you originally built your project using the service, you will need to convert it to use the new official service.

Updating the Endpoints in your composer.json #

The first thing you need to do is to add the appropriate composer repository to your composer.json. Remember that provides separate endpoints for each Platform version of Drupal. For Drupal 7 use For Drupal 8, use
If your composer.json already has a repositories link that points to, and does not have additional repositories in it, then you can run the following command on the command line to replace it:
composer config repositories.0 composer

Your composer.json repository section should end up looking like this:

    "repositories": [
            "type": "composer",
            "url": ""

At the same time, you will likely want to remove the Drupal Packagist composer repository.

Updating the versions of your declared dependencies #

When using Drupal Packagist - the semver shim format was: Platform(D7/D8).Major.Minor. So for example, the following code required Views 7.x 3.13 through Drupal Packagist:

    "require": {
        "drupal/views": "7.3.13"

When using the official service, the platform part of the version is already defined by whether you are using the Drupal 7 or Drupal 8 endpoint, therefore the rest of the translated format is as follows: Major.Minor.0

    "require": {
        "drupal/views": "3.13.*"

To convert to the new format, you should update your require statements appropriately in your composer.json and either rebuild your composer.lock file, or manually edit it.

Features not yet supported

  • Drupal does not yet have a sub-tree split - installing Drupal with composer will install the full package, same as you would receive from the tarball.
  • In the same vein, sub-components of Drupal core cannot be separately installed with Composer (such as the plugin manager).
  • Distributions and install profiles are not yet supported.
  • Drush extensions are not yet supported.


What to do if you suspect is causing an issue

The composer services work by generating static files with the metadata for the project translated for Composer. These static files are updated every time meta data about the package changes. If you know that information about a project has changed, but Composer is still getting the old information that may indicate a problem with the cache invalidation of these static files, or with packaging itself.

You can open an issue in the (project_composer) issue queue.

What to do if Composer is failing to recognize the Drupal project you have required in your Composer.json

First, make sure that you are using the right endpoint for the major version of Drupal Core that the project you are trying to include is for. Contributed projects for Drupal 8 will only be accessible on the Drupal 8 endpoint, and the same for Drupal 7

Second, check the require format you are using to require the project, using the examples above. Double check that you are using the suggested format. Eventually, the Project page will display the Composer require line that should be added to your Composer.json file, but that feature is still under development.

What if there is a namespace collision between two modules in different Projects?

There can be issues with conflicting module names on While Projects themselves must have unique names, the modules within projects do not have to be unique.

This kind of namespace collision most often occurs when a module is either moved into or out of core. One example of this is CKEditor, which has been moved into core.

This problem can be much more prevalent with themes, as many theme projects have a subtheme that is simply named default.

Whenever a collision does occur, the most popular module will be defaulted to for that namespace, and the other colliders will be given a new namespace of the format: project_modulename. For example: drupal/link-link for the link module.