Composer 2.11 RC Removes Source Fallback Override, Prompting Drupal Build Checks

Ahead of its next stable release, Composer has removed the temporary source-fallback configuration option in version 2.11.0-RC1, published on 22 October 2026. The option allowed a failed distribution archive download to retry using a source-code checkout. Composer lists its removal as a backward-compatibility change.

For Drupal teams using private repositories and automated builds, the change matters if a pipeline still depends on that recovery mechanism. A Git checkout can remain accessible even when the corresponding ZIP archive cannot be downloaded. Under these conditions, the unavailable archive can interrupt dependency installation before the Drupal application is deployed.

The removal completes a change introduced with Composer 2.10.0 on 28 May 2026, when automatic fallback from distribution archives to source checkouts was disabled by default. Composer temporarily retained the source-fallback option so administrators could restore the earlier behaviour while maintainers reviewed affected use cases. An earlier report by The DropTimes covered the change alongside Composer's new malware filtering and dependency security policies.

The merged implementation for Composer 2.11 removes the configuration override and prevents failed distribution installations from switching automatically to a source checkout. Composer maintainers have identified security concerns with silently changing installation sources, particularly when a source repository might provide different code from the intended distribution artifact. The restriction applies specifically to the distribution-to-source direction; fallback from a failed source installation to a distribution archive remains supported.

Composer continues to support deliberate source installation through its preferred-install configuration and the --prefer-source command-line option. These settings establish an installation preference rather than restoring automatic fallback after a distribution download fails. They can also be overridden by a build command that explicitly requests distribution installation.

A documented Drupal deployment problem illustrates the distinction. A participant in Composer issue #12889 described a project using the private awmemorial/awm_drupal_profile package hosted on GitHub and deployed through Upsun. Under Composer 2.10, the build reportedly encountered HTTP 404 errors when downloading private repository archives, while enabling source-fallback allowed installation to continue through Git.

According to the issue reporter, removing the temporary fallback setting caused the deployment to fail, despite the project's existing preference for source installation. Subsequent discussion identified the hosting platform's use of --prefer-dist as the reason the project-level preference was not taking effect. Participants described a workaround that replaced the default build command with a custom Composer installation command omitting that flag, and the reporter acknowledged the explanation.

The case predates Composer 2.11.0-RC1 and does not establish a new regression in the release candidate. It nevertheless demonstrates why removing the temporary override may affect teams that resolved similar problems without correcting the underlying installation configuration. The relevant distinction is whether Composer selects a source checkout from the outset or attempts one only after a distribution download fails.

Another participant in the same issue described a separate problem involving a self-hosted GitLab Composer Registry and development-branch packages. According to the report, newer commits could replace distribution artifacts while an existing composer.lock continued to reference an earlier commit. The locked source revision remained accessible through Git, but the missing archive could prevent installation and interrupt automated dependency-update workflows. This was a reported registry-specific problem, not evidence of a general incompatibility affecting Drupal packages.

Drupal teams preparing for Composer 2.11 should inspect their project and build configurations for source-fallback, preferred-install, --prefer-dist and --prefer-source. The command composer config --list --source can help identify effective configuration values and their origins, while composer --version identifies the installed Composer release. Hosted build commands, globally configured preferences and private repository credentials should also be reviewed because they may differ from the settings committed to composer.json.

For a controlled compatibility test, teams can use a disposable project containing a package with an accessible Git source and an intentionally unavailable distribution archive. Comparing installation behaviour under Composer 2.10 with the temporary fallback enabled and Composer 2.11.0-RC1 without that option can reveal whether an existing pipeline depends on the removed behaviour. A separate test using explicit source preference can establish whether that configuration works with the project's repository authentication and build commands.

Composer 2.11.0-RC1 also raises the composer-plugin-api version to 2.11.0. Drupal projects using Composer installers, scaffold plugins and other installation tools should check applicable plugin constraints and test the complete installation process. The API version change does not, by itself, establish that existing Drupal Composer plugins are incompatible.

Separately from download fallback behaviour, Composer 2.11 introduces an optional package-release cooldown policy. Administrators can specify a waiting period before newly published package versions become eligible for dependency resolution, reducing immediate exposure to potentially compromised releases. A 24-hour cooldown, for example, can prevent a newly published version from being selected during composer update or composer require until the period expires.

The cooldown is disabled by default and does not normally reselect package versions during composer install from an existing lock file. Its operation also depends on release timestamps supplied by package repositories. Composer-format repositories must provide a published-time value for considered package versions when the policy is active, unless the repository is configured to permit a fallback to the less authoritative package timestamp.

Drupal's recommended project configuration uses https://packages.drupal.org/8 for Drupal packages. Teams evaluating the cooldown should therefore verify that their configured repositories provide the metadata required by Composer 2.11. No incompatibility involving Drupal.org's package repository has been established by the available evidence.

The waiting period also requires consideration when applying urgent security updates. A newly released Drupal or PHP dependency fix may remain ineligible during a configured cooldown, even when administrators need to install it immediately. Composer 2.11 introduces --no-cooldown for supported dependency-update commands, allowing the waiting period to be bypassed for a single operation while leaving other security policies active.

The release candidate includes further security changes involving TLS certificate validation, generated binary proxies, insecure repository URLs and the handling of authentication headers. Composer's maintainers are inviting developers to test the release and submit regression reports with reproducible details. Their release instructions provide composer self-update --preview for accessing the candidate and composer self-update --stable for returning to the stable channel. Composer identifies 2.11.0-RC1 as a prerelease and is inviting regression reports before the stable release.