In Composer, what does the generated vendor/composer/platform_check.php do, and how does the platform-check config setting change it?

## Why a runtime check exists Composer checks platform requirements (`php`, `ext-*`) when it **resolves or installs** packages, on the machine running Composer. But code is often installed in one place and **run** in another: a build container on PHP 8.5, a production host still on 8.3; a CLI with an extension that the FPM pool lacks. Without a runtime check, the first sign is an obscure parse error or an undefined function deep inside a dependency. Composer 2.0 added a cheap guard that runs where the code runs. ## What the generated file does When the autoloader is dumped (by `install`, `update` or `dump-autoload`), Composer computes, from the **non-dev** installed packages: - the **highest lower bound** of all `php` requirements, for example 8.2.0 if one package needs `>=8.1` and another `^8.2`; - whether any package requires `php-64bit`; - with `platform-check` set to `true`, the list of required `ext-*` extensions, skipping any that another package provides or replaces. It writes these as plain PHP comparisons into `vendor/composer/platform_check.php`, which the autoloader bootstrap requires before registering anything else. When a check fails, the file: 1. sends `HTTP/1.1 500 Internal Server Error` if headers have not been sent; 2. if `display_errors` is off, writes `Composer detected issues in your platform:` and the list of issues to STDERR on the CLI, or to the output on the web when headers are not yet sent; 3. throws a `RuntimeException` carrying the same message. Composer's runtime documentation describes the failure as exiting with code 104; the generated code in Composer 2.10 throws the exception instead, so the process ends with an uncaught exception. ## The `platform-check` setting | Value | What is checked | File generated | |---|---|---| | `"php-only"` (default) | PHP version lower bound, 64-bit if required | yes, if there is a requirement | | `true` | the above plus presence of each required `ext-*` | yes | | `false` | nothing | no | ```json { "config": { "platform-check": true } } ``` With `true`, extensions are checked for **presence only**: `extension_loaded()`, not version, for performance. `pcntl` and `readline` are checked only on the CLI, where they belong. ## What it does not check - **Upper bounds.** A package that declares `php <8.4` is not stopped on 8.5 by this file; only the lowest required version is enforced. - **`lib-*` requirements**, never. - **Dev packages**, skipped on purpose: the check is a production safeguard. - Requirements you told Composer to ignore: `dump-autoload --ignore-platform-req=ext-foo` also leaves that requirement out of the check. ## Reading a failure A typical production message, taken from the generated code, reads: `Composer detected issues in your platform: Your Composer dependencies require a PHP version ">= 8.3.0". You are running 8.2.20.` With `platform-check` set to `true`, a missing extension adds a line saying the dependencies require the following PHP extensions to be installed, followed by their names. Both mean the same thing: the code was installed for a different runtime than the one executing it. Typical causes are a CLI and a web server on different PHP versions on the same host, a container image built from one base and run on another, or a PHP downgrade after a rollback. ## Where it fits in a deploy The runtime check turns a confusing failure into a clear one, but a clear HTTP 500 in production is still an outage. Composer's own recommendation is to run `composer check-platform-reqs` against the real runtime during the build or deploy, and abort on a non-zero exit. That command checks the real PHP and extensions, ignores `config.platform`, and fails before traffic reaches the new release. Disable the runtime check (`false`) only with a reason: for example, when the CLI that dumps the autoloader and the web SAPI legitimately differ in a way the check misreads, and the build already verifies the real runtime.