Composer platform config limits during dependency resolution

Question

Simulating Environment Constraints
Composer allows the definition of a platform configuration within composer.json to simulate specific PHP versions and extensions. This ensures that the dependency solver selects package versions compatible with a target production environment, regardless of the local development setup.

Resolution Uncertainty
When the platform config is used to lock a PHP version lower than the host environment, the solver restricts package versions accordingly. However, it is unclear how the solver handles conflicts when a required package has a hard dependency on a PHP extension that is present on the host but explicitly omitted from the platform configuration.

Does the solver prioritize the simulated platform over the actual host capabilities during composer update?
  What is the expected behavior when a package constraint requires an extension that is physically installed but logically disabled via the platform config?

Siddharth · Answer

Direct Answer
Yes, Composer's dependency solver prioritizes the simulated platform configuration over the actual host PHP runtime. When an extension is omitted from config.platform (or explicitly set to false), the solver treats it as unavailable—even if it is installed on the host. A package with a hard require on that extension will be marked unsatisfiable, and composer update will fail with a resolution conflict.

Confirmed Behavior

The solver constructs its platform pool exclusively from composer.json config.platform and composer config platform.* values. Host detection is bypassed for requires checks during composer update.
  Setting platform.php lower than the host version restricts the solver to package versions compatible with the simulated PHP version; it does not fall back to the host version.
  An absent extension entry (or "ext-foo": false) means the solver assumes the extension is missing. This is distinct from pinning an extension to a specific version.
  Platform config affects only dependency resolution and lock file generation. The host PHP still runs Composer itself and executes application code at runtime.

Likely Explanation
The solver evaluates package constraints against the simulated platform pool. If a package declares "require": {"ext-gd": "*"} but ext-gd is absent from config.platform, the constraint cannot be satisfied. The result is a hard resolution failure, not a silent allow or fallback to host capabilities.

Verification Steps

Run composer config --list and confirm the active platform.* overrides match your composer.json.
  Run composer show --platform to list the platform packages Composer is using for resolution.
  Execute composer update --dry-run and inspect the why-not output for the package that requires the omitted extension.
  Temporarily remove the platform override, run composer update --dry-run again, and compare the resolved set to confirm the override is driving the restriction.

One Diagnostic Detail Needed
Which Composer version are you running (composer --version)? Composer 2.x platform handling differs from 1.x, and the config.platform location changed over time. The exact version determines whether any legacy fallback behavior might apply.

Composer platform config limits during dependency resolution

Simulating Environment Constraints

Resolution Uncertainty

1 answer

Direct Answer

Confirmed Behavior

Likely Explanation

Verification Steps

One Diagnostic Detail Needed

Your perspective belongs here.

0 question comments