· ReadyStack
Worked example
Real numbers from this tool, line by line.
This composer.json still allows end-of-life PHP 7.4: the sample file a PHP package maintainer might tag for Packagist gives 10 findings, 4 errors and 6 warnings, and composer validate --strict reports only one of them.
Here is the sample. Its require block says "php": "^7.4 || ^8.0". PHP 7.4 reached end of life on 2022-11-28, PHP 8.0 on 2023-11-26 and PHP 8.1 on 2025-12-31, according to php.net. PHP 8.2 follows on 2026-12-31. Every tag you push with that floor tells Composer, and every user who installs your package, that an unpatched PHP runtime is a supported target.
The same file pins config.platform.php to "7.4.33". That line is easy to forget: it makes Composer resolve every dependency as if the machine ran PHP 7.4, so the lock file keeps pulling versions built for a runtime nobody patches.
Then come the Packagist fields. The name is "Acme/Invoice_Tools". Composer's schema wants lowercase vendor/package, so composer validate --strict fails right there with the regex error and stops. It never tells you that the description is also missing, which is a publish error of its own, or that the licence array holds "GPL" (not an SPDX id) and "LGPL-2.1+" (a deprecated SPDX id whose replacement is "LGPL-2.1-or-later"). You fix one line, run it again, and meet the next one.
The warnings are the quieter part. The file sets a version field, "1.4.0", although Packagist reads versions from git tags. It requires guzzlehttp/guzzle at "*" and symfony/console at ">=5.4", two unbound constraints that accept any future major. It pins psr/log to exactly "1.1.4", which Composer flags as an exact version constraint.
composer.json Validate - PHP EOL Release Gate reads the whole file at once. It has 14 rules: the PHP floor against the php.net table, a warning when the floor branch ends within 180 days, a missing php constraint, config.platform.php, the name pattern, missing name or description, missing, non-SPDX or deprecated licence ids (575 current ids, taken from the list Composer itself ships), the version field, and unbound or exact constraints. The Composer wording was reproduced with Composer 2.7.1 on 2026-09-30.
Each finding carries the replacement line. On 2026-09-30 the PHP fix is "php": "^8.3", because 8.3 is the oldest branch with more than 180 days of security support left (it runs to 2027-12-31). The name fix is "acme/invoice-tools". The deprecated licence becomes "LGPL-2.1-or-later". The exact pin becomes "^1.1.4".
Run the cleaned file and the count is 0.
The date matters. If your floor is "^8.2" today, the tool gives a warning: security support ends 2026-12-31. Open the same file on 2027-01-15 and the warning becomes an error, with the same "^8.3" fix. Nothing in composer validate changes on that day, which is why a chatbot or the validator alone will not tell you.
The check of the open file is free, in VS Code or in the browser page, and it finishes the job for one package. The full version sweeps every composer.json in the workspace, monorepo packages included, and writes a dated Markdown release report you keep with the tag. For scale: a PHP developer's hour costs about $65.38 at the US median wage for software developers (BLS OEWS 2025).
15 seconds — what it actually does
Questions people ask
What does composer.json Validate - PHP EOL Release Gate do?
It reads a composer.json and flags a require.php floor that still allows an end-of-life PHP branch (8.1 ended 2025-12-31, 8.2 ends 2026-12-31), a config.platform.php pinned to one, and the fields composer validate --strict rejects before a Packagist release: name, description, SPDX licence, version field and unbound or exact constraints. Each finding prints the replacement line. 14 rules.
Who is this composer.json checker for?
PHP package maintainers who publish libraries or plugins on Packagist, and agency developers who keep several internal Composer packages. It suits anyone tagging a release who wants the PHP support floor and the composer validate --strict publish fields right before the tag goes out, especially with PHP 8.2 reaching end of life on 2026-12-31.
Why not just run composer validate --strict?
composer validate --strict stops at the first schema error: on the bundled sample it prints only the uppercase name error, while this tool lists all 10 findings. It also never compares the require.php floor with php.net end-of-life dates, so "php": "^7.4 || ^8.0" passes it. A chatbot often quotes old support dates for PHP 8.1 and 8.2.
What is free and what does the full version add?
Free, without a key: check the open composer.json in VS Code or in the browser page, with every finding and its fix line. That finishes one package. The full version ($29 once, one licence key per person or team seat) sweeps every composer.json in the workspace and writes a dated Markdown release report you keep as proof.
What does it cost compared with doing it by hand?
Checking a composer.json by hand means reading php.net support dates, the Composer schema and the SPDX list. A PHP developer's hour costs about $65.38 (US median wage for software developers, BLS OEWS 2025). The free check costs nothing; the full version is $29 once, for workspace sweeps and dated release reports.
Ask about this tool
One question, answered by the person who built it. Your email only if you want the answer sent.