Composer 2.0 is now available

What's new?

The list of changes and improvements is long, check the complete changelog if you are interested in reading it all. I will highlight a few key points here.

Performance improvements

We overhauled pretty much everything from the protocol used between Composer and packagist.org to the dependency resolution, including downloading files in parallel using curl and constraint evaluation optimizations.

This leads to massive improvements in terms of both speed and memory usage.

The difference depends on your use case, so while I've seen reports of improvements of over 50% to both in some projects, I cannot put an exact number on it.

As a side note to this, require/remove and partial updates are now much faster because Composer will now only load the metadata of the packages which are being changed.

Time for initial update + install (bootstrapped project, empty cache) shows roughly 60% less time used by Composer 2 with ext-curl enabled

Architectural changes and determinism

The way dependency updates are done internally was refactored, which, for you, will result in more deterministic updates. The current local state of the vendor directory will not interfere in updates anymore.

After an update is complete, the install process is run automatically and it will now execute all network bound operations first - and in parallel if possible. This will avoid leaving you with a half-updated vendor directory if a network error occurs midway through installation.

Runtime features

We added a platform-check step when vendor/autoload.php gets initialized which checks the current PHP version/extensions match what is expected by your dependencies and fails hard otherwise. This is enabled by default so make sure you read up on it to avoid surprises.

There is a new class, Composer\InstalledVersions, which is autoloaded in every project and is available at runtime. It allows you to check which packages/versions are present at runtime of your own project.

See the runtime docs for more details.

If your code relies on any of these runtime features, you should require "composer-runtime-api": "^2.0" in your composer.json. This is a virtual package which is provided by Composer and will make sure people have to use Composer 2.x to install your package.

Error reporting improvements

Because things don't always go the way they're supposed to, we made sure to improve the error reporting shown to you when dependencies cannot be resolved. It's hard to give concrete examples here as there are a million ways this can fail but you will hopefully notice that messages are now shorter, clearer and less repetitive.

Partial updates with temporary constraints

Sometimes it can be useful to upgrade or downgrade a single package to a specific version, perhaps temporarily to test something or wait for a bug fix. You can now run composer update vendor/package:1.0.* for example (or 1.0.12 or any other version constraint), to run an update of only vendor/package to a version matching this additional constraint. This will not update your require in composer.json, and it will not mark the lock file out of date.

If you want to add/restrict a constraint but still do a full update of all dependencies, you can use update --with vendor/package:1.0.* which will run the update with that additional constraint.

Easy is it to upgrade

Our goal is that every Composer user can upgrade smoothly and swiftly. The gains are huge and we want everyone to benefit from them. To achieve that we did a few things:

• Composer 2.0 still supports PHP 5.3 and above, much like Composer 1.x
• composer.lock files are interoperable between versions, so you can upgrade to 2.0 and roll back easily if needed.
• Most commands and arguments remain the same, and largely what you know about Composer remains true in 2.0.

If you run composer self-update from 1.x, it will warn you that a new stable major version of Composer is available, and you can use composer self-update --2 to migrate to it.

Should you encounter issues, you can go back at any time by using composer self-update --1.

Hopefully that will make everyone feel comfortable to experiment with the new release.

If you are installing Composer automatically from the installer script, and wish to remain on Composer 1.x for the time being, you can also pass it a --1 argument to prevent it from installing Composer 2.0 by default.

If you do this please remember and aim to upgrade in a timely manner, as Composer 1.x will not be maintained for very long.

Upgrade:   composer self-update --2

Rollback:   composer self-update --rollback

Most used command

require

The require command adds new packages to the composer.json file from the current directory. If no file exists one will be created on the fly.

php composer.phar require

After adding/changing the requirements, the modified requirements will be installed or updated.

If you do not want to choose requirements interactively, you can pass them to the command.

php composer.phar require "vendor/package:2.*" vendor/package2:dev-master

If you do not specify a package, composer will prompt you to search for a package, and given results, provide a list of matches to require.

Options

• --dev: Add packages to require-dev.
• --dry-run: Simulate the command without actually doing anything.
• --prefer-source: Install packages from source when available.
• --prefer-dist: Install packages from dist when available.
• --no-progress: Removes the progress display that can mess with some terminals or scripts which don't handle backspace characters.
• --no-update: Disables the automatic update of the dependencies (implies --no-install).
• --no-install: Does not run the install step after updating the composer.lock file.
• --no-scripts: Skips execution of scripts defined in composer.json.
• --update-no-dev: Run the dependency update with the --no-dev option.
• --update-with-dependencies (-w): Also update dependencies of the newly required packages, except those that are root requirements.
• --update-with-all-dependencies (-W): Also update dependencies of the newly required packages, including those that are root requirements.
• --ignore-platform-reqs: ignore all platform requirements (php, hhvm, lib-* and ext-*) and force the installation even if the local machine does not fulfill these. See also the platform config option.
• --ignore-platform-req: ignore a specific platform requirement(php, hhvm, lib-* and ext-*) and force the installation even if the local machine does not fulfill it.
• --prefer-stable: Prefer stable versions of dependencies.
• --prefer-lowest: Prefer lowest versions of dependencies. Useful for testing minimal versions of requirements, generally used with --prefer-stable.
• --sort-packages: Keep packages sorted in composer.json.
• --optimize-autoloader (-o): Convert PSR-0/4 autoloading to classmap to get a faster autoloader. This is recommended especially for production, but can take a bit of time to run, so it is currently not done by default.
• --classmap-authoritative (-a): Autoload classes from the classmap only. Implicitly enables --optimize-autoloader.
• --apcu-autoloader: Use APCu to cache found/not-found classes.
• --apcu-autoloader-prefix: Use a custom prefix for the APCu autoloader cache. Implicitly enables --apcu-autoloader.