Question
Platform requirement mismatch during runtime execution in Composer 2
Sky Byte
0 reputation · 23 Feb 2025, 04:30 UTC
89.3K views1
Loading…
0 reputation · 23 Feb 2025, 04:30 UTC
Composer treats php, ext-*, and lib-* as virtual packages during dependency resolution. While the resolver ensures that the selected package versions are compatible with the detected environment, the config.platform setting allows developers to override these detected versions to simulate a different environment during the update process.
The platform-check feature generates a check in the vendor autoload path to identify missing requirements at runtime. However, a discrepancy arises when config.platform is used to satisfy dependencies that are not actually present on the target production server, potentially bypassing installation-time guards.
Given that resolution inputs can be configured independently of the actual runtime facts, it is unclear how to strictly enforce environment parity without manually disabling configuration overrides.
config.platform completely supersede the runtime platform check generated in the autoload files?config.platform overrides do not lead to missing extension errors in production?32275 reputation · 23 Feb 2025, 05:36 UTC
No, config.platform does not supersede the runtime platform check. They operate at two entirely different stages of the application lifecycle: config.platform influences the dependency resolution phase, while the platform check validates the execution environment.
When you define config.platform in composer.json, you are instructing the Composer solver to ignore the local environment's actual PHP version and extensions. This allows you to generate a composer.lock file that is compatible with a target production server, even if your local development machine lacks those specific requirements.
The runtime guard (found in vendor/composer/platform_check.php) is generated during the installation process. It records the requirements of the packages selected in the lock file and compares them against the actual PHP environment at bootstrap. If config.platform was used to "fake" an extension during resolution, the runtime check will still detect its absence on the production server and trigger a fatal error.
To ensure that simulated environments do not lead to production failures, follow these practices:
composer
phpconfig.platform to mirror the exact specifications of your production environment. Do not use it to bypass requirements that are actually needed.check-platform-reqs command into your CI/CD pipeline. This verifies the composer.lock requirements against the actual environment without performing a full installation.config.platform-check remains enabled (the default in Composer 2). Disabling this removes the only automatic safety net that prevents the application from booting with missing extensions.You can verify the current state of your environment and overrides using these commands:
# Compare configured overrides vs. detected platform facts
composer config platform
composer show --platform
# Manually verify lock file requirements against current environment
composer check-platform-reqsTo confirm the runtime guard is active, inspect vendor/composer/platform_check.php after an install to see which PHP versions and extensions are being explicitly enforced.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.