The Ultimate Guide to drupal/core-* packages

In this guide, you will find all the information about various drupal/core-* packages. Let's see what all these packages are and what they do.

drupal/core vs drupal/core-recommended

What is Drupal core recommended?

By using drupal/core-recommended (packagist link) package you are making sure that all Drupal dependencies will be included in your project at exactly the same versions that were used to test a given version of Drupal core. In other words, dependencies are locked to specific versions as you can see in the screenshot below.

This will prevent the required packages to float up to the more recent versions than were tested with Drupal. Using this package is a small but important step in the process of ensuring the overall stability of your project. To migrate from drupal/core to drupal/core-recommended first require the new package:

composer require --update-with-all-dependencies drupal/core-recommended

and then remove the old package:

composer remove --no-update drupal/core

If you take a look at the drupal/core (packagist link) you'll see that packages aren't locked to specific versions, and that can lead to various issues if new dependency versions introduce bugs.

How do I update Drupal core modules?

Switching to the core-recommended package also means that from now on to update Drupal core with Composer you have to use the following command:

composer update --with-dependencies drupal/core-recommended

drupal/core-dev

What is Drupal core dev?

Unless you are a Drupal developer and you want to run tests, you don't need this package. As the name suggests, this package will install development dependencies. Those are tools like Behat Mink, PHPUnit, Prophecy, PHPStan, and Coder. To install the package, run:

composer require --dev drupal/core-dev

Make sure to use the --dev option to add the package to the require-dev section. Then when you run composer install --no-dev on your build/production server you won't install dev dependencies.

Some older versions of Drupal have dev dependencies required one by one in the require-dev section as you can see in the screenshot below. You can remove all of them (use for example composer remove --dev --no-update behat/mink) and replace them with just the drupal/core-dev package.

drupal/core-project-message

What is Drupal core project message?

It's a Composer plugin used to display messages in the terminal after Composer installation processes (composer create-project or composer install) have finished. Drupal core is using this plugin to inform the users what they should do next after installing the codebase.

To find out how to configure it click here. You can safely remove this package if you don't want to see messages.

drupal/core-vendor-hardening

What is the vendor folder in Drupal?

The vendor directory is the place where Composer stores all third-party dependencies. For example, Drupal depends on various Symfony packages, and they all will be stored in the vendor directory.

The vendor directory should always be placed outside of the server's docroot directory to mitigate security concerns. In other words, it shouldn't be publicly available over HTTP. But if for some reason that's not possible, you can use the drupal/core-vendor-hardening plugin to harden the vendor directory. It works by removing unneeded directories from the vendor directory and also placing .htaccess and web.config files within the directory.

Run the following command to install the plugin:

composer require drupal/core-vendor-hardening

and the hardening will happen automatically.

drupal/core-composer-scaffold

What is Drupal core composer scaffold?

It's a Composer plugin used for placing scaffold files (like index.php, README.md, robots.txt, and so on) from the drupal/core project into their desired location inside the webroot. You can see the scaffolding files for Drupal 9.4 in the screenshot below. As you can see they are copied from the assets directory to your project root and webroot directories.

The scaffolding operations run automatically as needed, for example after composer install, so you don't have to do anything once you configure the plugin in your composer.json file. Usually, people configure at least the location of their webroot:

"name": "drupal/my-project",
...
"extra": {
  "drupal-scaffold": {
    "locations": {
      "web-root": "web/"
    },
    ...
  }
}
...

or they exclude some files from scaffolding:

"name": "drupal/my-project",
...
"extra": {
  "drupal-scaffold": {
    "file-mapping": {
      "[web-root]/sites/development.services.yml": false,
      "[web-root]/.htaccess": false
    },
    ...
  }
}
...

Excluding files is useful if you made some updates to these files (like robots.txt and .htaccess) and you don't want to lose the changes. This also means that you won't get any bug fixes or other updates to these files, so be aware of that.

This plugin is available in Drupal core as of the 8.8.x, and before that people mostly used the drupal-composer/drupal-scaffold plugin which is now deprecated and shouldn't be used. For more information about the usage of the drupal/core-composer-scaffold plugin check the official docs.