New Features and Event‑Flow Changes in Composer 2

Composer 2 introduces a series of new command‑line features and behavioural changes aimed at improving dependency management, platform compatibility, and overall developer experience.

1. New Features

For CLI users

The platform‑check feature validates the runtime PHP version and installed extensions against project requirements; on mismatch it aborts and displays detailed errors. It is recommended to run composer check-platform-reqs during build or deployment.

If a package exists in a higher‑priority repository, it is now completely ignored in lower‑priority repositories. See repository priority documentation for details.

Invalid PSR‑0/PSR‑4 class configurations are no longer silently autoloaded when the optimizer is enabled; a warning introduced in 1.10 is now an error.

On Linux systems that support the XDG base directory spec, Composer prefers XDG_CONFIG_DIR/composer over ~/.composer when both are available (the older behaviour is used in 1.x).

Package names must now conform to Composer’s naming guidelines, otherwise an error aborts the operation ( schema reference ).

The --no-suggest flag is deprecated and no longer needed.

PEAR support (repositories, downloaders, etc.) has been removed.

During update , Composer first lists changes to the composer.lock file (the update step) and then lists changes applied when the lock file is installed to the vendor directory (the install step).

If HTTPS_PROXY_REQUEST_FULLURI is not set, it now defaults to false , which works better in most environments.

Branch aliases such as dev-trunk , dev-master , and dev-default are no longer aliases of each other; Composer now retains the exact branch name.

2. Detailed Differences in Dependency Resolution, Update, and Install Event Flow

Composer v1

Composer resolves dependencies (schedules PRE/POST_DEPENDENCIES_SOLVING ).

It then iterates over all packages, scheduling PRE_PACKAGE_INSTALL / UPDATE / UNINSTALL , optionally PRE_FILE_DOWNLOAD , followed by POST_PACKAGE_* events.

Finally, the lock file is written at the end.

Composer v2

The update and install processes have been split.

Update phase:

Composer resolves dependencies (schedules PRE_POOL_CREATE ).

The lock file is written and the update phase ends.

Install phase:

Composer sends the full list of operations to PRE_OPERATIONS_EXEC .

All packages not already cached are downloaded in parallel (schedules PRE_FILE_DOWNLOAD for each).

It then iterates over all packages, executing update/install/uninstall in parallel: dispatches PRE_PACKAGE_INSTALL / UPDATE / UNINSTALL , then publishes POST_PACKAGE_* events, with possible interleaving of operations across packages.