You Should Upgrade To Composer 2

[Edilma Howard]

Ifthere is a composer.lock file in the current directory, it will use theexact versions from there instead of resolving them. This ensures thateveryone using the library will get the same versions of the dependencies.

In order to get the latest versions of the dependencies and to update thecomposer.lock file, you should use the update command. This command is alsoaliased as upgrade as it does the same as upgrade does if you are thinkingof apt-get or similar package managers.

Note that with the above all packages will be updated. If you only want toupdate the package(s) for which you provide custom constraints using --with,you can skip --with and instead use constraints with the partial update syntax:

Note: For packages also required in your composer.json the custom constraintmust be a subset of the existing constraint. The composer.json constraints stillapply and the composer.json is not modified by these temporary update constraints.

Specifying one of the words mirrors, lock, or nothing as an argument has the same effect as specifying the option --lock, for example composer update mirrors is exactly the same as composer update --lock.

The bump command increases the lower limit of your composer.json requirementsto the currently installed versions. This helps to ensure your dependencies do notaccidentally get downgraded due to some other conflict, and can slightly improvedependency resolution performance as it limits the amount of package versionsComposer has to look at.

Running this blindly on libraries is NOT recommended as it will narrow downyour allowed dependencies, which may cause dependency hell for your users.Running it with --dev-only on libraries may be fine however as dev requirementsare local to the library and do not affect consumers of the package.

The reinstall command looks up installed packages by name,uninstalls them and reinstalls them. This lets you do a clean installof a package if you messed with its files, or if you wish to changethe installation type using --prefer-install.

The check-platform-reqs command checks that your PHP and extensions versionsmatch the platform requirements of the installed packages. This can be usedto verify that a production server has all the extensions needed to run aproject after installing it for example.

Lists all packages suggested by the currently installed set of packages. You canoptionally pass one or multiple package names in the format of vendor/packageto limit output to suggestions made by those packages only.

The prohibits command tells you which packages are blocking a given packagefrom being installed. Specify a version constraint to verify whether upgradescan be performed in your project, and if not why not. See the followingexample:

setting-key is a configuration option name and setting-value1 is aconfiguration value. For settings that can take an array of values (likegithub-protocols), multiple setting-value arguments are allowed.

To create a new project using Composer you can use the create-project command.Pass it a package name, and the directory to create the project in. You can alsoprovide a version as a third argument, otherwise the latest version is used.

Additionally, it can dump an optimized autoloader that converts PSR-0/4 packagesinto classmap ones for performance reasons. In large applications with manyclasses, the autoloader can take up a substantial portion of every request'stime. Using classmaps for everything is less convenient in development, butusing this option you can still use PSR-0/4 for convenience and classmaps forperformance.

You can set a number of environment variables that override certain settings.Whenever possible it is recommended to specify these settings in the configsection of composer.json instead. It is worth noting that the env vars willalways take precedence over the values specified in composer.json.

If set to 1, this env disables the warning about running commands as root/super user.It also disables automatic clearing of sudo sessions, so you should really only set thisif you use Composer as a super user at all times like in docker containers.

The COMPOSER_AUTH var allows you to set up authentication as an environment variable.The contents of the variable should be a JSON formatted object containing http-basic,github-oauth, bitbucket-oauth, ... objects as needed,and following thespec from the config.

You may put a config.json file into the location which COMPOSER_HOME pointsto. Composer will partially (only config and repositories keys) merge thisconfiguration with your project's composer.json when you run the install andupdate commands.

This lets you hint under which environment Composer is running, which can help Composerwork around some environment specific issues. The only value currently supported isvirtualbox, which then enables some short sleep() calls to wait for the filesystemto have written files properly before we attempt reading them. You can set theenvironment variable if you use Vagrant or VirtualBox and experience issues with files notbeing found during installation even though they should be present.

Set to an integer to configure how many files can be downloaded in parallel. Thisdefaults to 12 and must be between 1 and 50. If your proxy has issues withconcurrency maybe you want to lower this. Increasing it should generally not resultin performance gains.

If COMPOSER_IGNORE_PLATFORM_REQS set to 1, it is the equivalent of passing the --ignore-platform-reqs argument.Otherwise, specifying a comma separated list in COMPOSER_IGNORE_PLATFORM_REQ will ignore those specific requirements.

For example, if a development workstation will never run database queries, this can be used to ignore the requirement for the database extensions to be available. If you set COMPOSER_IGNORE_PLATFORM_REQ=ext-oci8, then composer will allow packages to be installed even if the oci8 PHP extension is not enabled.

I'm just starting to work with Drupal 8 and composer and I'm trying to figure out how the updating workflow should work. I know the basics from administering a Drupal 7 server for years, but the Composer part is tripping me up.

Right now I run, from the root folder of my Drupal install, (with maintenance mode enabled) composer outdated and I get a list of a bunch of packages in need of an update.

As far as I can tell from the documentation, I should only be updating the packages that start with "drupal/". Assuming just the console and core come up as outdated, I run composer update drupal/console drupal/core --with-dependencies and that pulls down the updates, and does its thing. After this is done, if I run composer outdated again, I still see a bunch of packages that are outdated according to composer. Is that intended? Or should these packages be updated?

I'm guessing Drupal is built using specific versions of packages, so updating all of them would probably break some stuff, right? How is someone supposed to know what packages should be updated and which ones should stay at a specific version?

This is a fairly vanilla Drupal install. I only have a few modules added and one theme. I should probably also mention that this site was build using the drupal-composer template mentioned in the official docs ( -composer/drupal-project).

Honestly, for a codebase like your typical Drupal site, this is a hard problem to solve. Take, for instance, my Drupal VM Prod codebase, which I just upgraded from Drupal core 8.4.5 to 8.5.0 yesterday:

This listed off a ton of different symfony components... so I could've sat there and copy-pasted each of the 14 components into my composer update command, but that is not fun to do, so I kept poking around (to no avail).

Later in the comment thread, @eiriksm mentioned that since my project has symfony/config (a dependency of drush and drupal console), I needed to run composer update drupal/core symfony/config --with-dependencies.

I still have no idea how I could've figured out I just needed to add symfony/config in the update command (vs adding all the other symfony components)... but if I do, I'll try to update this answer with that information so others can benefit in the future!

I am coming to the conclusion that maybe composer update should be "embraced" and that one should manage module versions carefully in composer.json perhaps locking them all to the currently installed versions, then changing the version only when you want to update the module. That is really not that big a deal to do.

Composer has been around for 8 years performing its mission of a great assistant to developers in installing, updating, or removing all kinds of PHP packages. The major new version of this dependency management CLI tool was released in October 2020.

The dependency management tool has a noticeable performance boost, as well as memory and CPU usage optimization in its v2. Here are some of the changes that are very helpful for faster work without losing time:

Jordi Boggiano offers a comparison between v2 vs v1 performance for Drupal, Laravel, and Symfony. An initial update and installation for the Bootstrapped projects with an empty cache and ext-curl enabled take roughly 60% less time.

Composer 2 can partially work offline, which you may find very useful when having a slow connection or running a benchmark. The tool will try installing the packages based on the composer.lock file and the cached versions of the packages and metadata. To get this to work, you will need to:

The above-described features are just a few examples of what the new release of the dependency manager has to offer. All you need to do is to perform the upgrade so you can make the most of its new features and use a version with full support. But is it easy to do the upgrade?

We know from our experience how important it is to follow the best web development practices and use the newest versions of useful software. Hopefully, our post will inspire you to upgrade to Composer 2. Drop us a line if you ever need help from a strong web development team!

3a8082e126