What 3052 composer.json files tell us about the Composer plugin ecosystem

I like to read composer.json files the way other people read tea leaves. Take enough of them and patterns emerge: which packages everyone depends on, which ones are stuck two major versions behind, and what a minimum-stability field says about a maintainer’s risk tolerance.

For this post, I pulled every composer.json I could find under projects/*/code/ in my local Exakat corpus: 3285 project directories, 3054 of which actually ship a composer.json. Yes, I usually estimate that 2% of PHP application do not use composer.json. Not great, no bad.

I parsed all of them, and 3052 came back as valid JSON (two are broken, a separate post, maybe). Most of these projects are Composer plugins and installers: 42% declare type: composer-plugin, and composer-plugin-api shows up as a requirement in 40% of all files. So what follows is really a snapshot of the Composer plugin ecosystem specifically, not PHP at large: keep that in mind when you compare it to your own dependency tree.

Here’s what the numbers say.

PHP itself: how low do people set the floor

Before anything else, there’s the language itself. Only 1548 of the 3052 manifests, that is 50.7%, declare a php constraint at all. The other half either leaves compatibility entirely to composer-plugin-api, or simply doesn’t say. For a plugin that’s meant to install on a stranger’s machine, that’s a striking number of authors who never wrote down the one constraint that would actually stop it from running.

For the 1548 that do declare one, here’s the floor they set, the lowest PHP minor version each constraint would still accept, whether written as ^8.1, >=7.4, ~7.4 or an OR’d chain of ranges:

PHP 5
  5.0                                    2  (0.1%)
  5.1                                    2  (0.1%)
  5.2                                    3  (0.2%)
  5.3  ████████████████                106  (6.8%)
  5.4  ████████                         56  (3.6%)
  5.5  █████████                        63  (4.1%)
  5.6  ████████████                     82  (5.3%)

PHP 7
  7.0  ████████████                     77  (5.0%)
  7.1  █████████████████████           143  (9.2%)
  7.2  █████████████████               111  (7.2%)
  7.3  ███████████                      72  (4.7%)
  7.4  █████████████████████████       168  (10.9%)

PHP 8
  8.0  ████████████████████            135  (8.7%)
  8.1  ██████████████████████████████  200  (12.9%)
  8.2  ████████████████████████        158  (10.2%)
  8.3  ██████████████                   92  (5.9%)
  8.4  ██████████                       64  (4.1%)
  8.5  ██                               13  (0.8%)

Floor version implied by each project’s php constraint, out of the 1548 manifests that declare one.

PHP 8.1 alone is the single most common floor, for 200 projects or 12.9%, but it’s not a landslide: ^7.1, ^7.4, ^8.0 and ^8.2 are all close behind it. Group by major and the picture is more telling: PHP 8.x floors account for 42.8% of the declared constraints, PHP 7.x for 36.9%, and PHP 5.x, a version whose last release shipped over a decade ago, still accounts for 20.3%. One in five plugins that bothers to state a PHP version at all is still willing to run on PHP 5. Or so they claim.

The extensions people build against

2259 ext-* requirements, spread across 87 distinct extensions, appear in 583 composer.json: 19.1% of the corpus declares at least one. The head of the list is exactly what you’d expect from PHP core: JSON, mbstring, cURL, PDO, DOM. The tail is where it gets interesting: a long list of extensions required by exactly one project each, which is its own kind of signal about how specialized some of these extensions are.

Extension names normalized to lowercase (a handful of manifests write ext-SPL or ext-PDO); links go to the PHP manual for bundled extensions and to PECL or the project’s own repository for everything else. ext-encoding is left unlinked: I couldn’t confidently confirm what current package it maps to.

The long tail tells its own story: ext-swoole and ext-openswoole for async runtimes, ext-chunkutils2/ext-morton/ext-pmmpthread from the PocketMine-MP Minecraft-server project, ext-geos for geospatial computation, ext-wikidiff2 straight out of MediaWiki, ext-phalcon for a framework that ships as a compiled extension rather than a library. None of these are things you’d predict from a generic “PHP ecosystem” survey. They only show up because this corpus is Composer plugins specifically, each one built to solve one real, narrow problem.

That’s PHP and its extensions accounted for. What’s left is the actual software. They are the libraries, frameworks and tools people install on top of the platform to build their plugins.

Top 50 most required packages

19945 require entries across the corpus, spread over 5707 distinct package names: this time, real Packagist packages only, with php, ext-*, lib-* and composer-plugin-api/composer-runtime-api stripped out. Most of that 5707 is one-off dependencies used by a single plugin. Here’s the top of the distribution, with the most frequent components:

Symfony components own this list: 24 of the top 50 are symfony/*. Guzzle, Monolog, Doctrine and the PSR interfaces fill most of the rest. Laravel shows up too, with laravel/framework, laravel/tinker, illuminate/support, a reminder that plenty of these “Composer plugins” are actually Laravel packages that happen to also ship an installer.

Top 50 most required dev packages

require-dev is a much smaller and more concentrated world: 8474 entries, 1385 distinct packages, and a very predictable top of the table.

A third of the corpus tests with PHPUnit. Just over a quarter requires composer/composer itself in dev: this is expected, since a Composer plugin needs the Composer API to type-hint against and to run its test suite against real plugin activation. PHPStan alone, at 12.2%, is already well ahead of Psalm, at 2.6%, and counting the whole family together, phpstan/phpstan plus its satellites extension-installer, phpunit, strict-rules, deprecation-rules, symfony, 390 projects, or 12.8% of the corpus, use at least one of them. Pest is present, 2.7% but PHPUnit is still the default by an order of magnitude.

Requested versions vs. what’s actually on Packagist today

This is the part I find the most telling. For each of the most-required packages, I looked at every version constraint written across the corpus, broke ||-separated ranges into individual major versions, and compared the most commonly targeted major against the current stable release on Packagist.

A few things jump out:

• Guzzle is the most striking laggard — though partly excusable. 83% of the corpus is still pinned to ^7.x, and only 2% of projects declare a constraint that would accept Guzzle 8. In fairness, Guzzle 8.0.0 only shipped on 2026-07-20, barely a month before this scan: this is less “ecosystem laggard” and more “the ink isn’t dry yet.” Worth re-running this query in six months.
• The Symfony components are all in the same boat. Console, Yaml, Filesystem, Finder, Process, EventDispatcher: every one of them peaks around major 6 or 7, while Symfony itself is already shipping 8.x. Given Symfony’s yearly major-version cadence, this isn’t really about laziness; a ^6.0 constraint from a couple of years ago is simply not the kind of thing a plugin maintainer revisits unless something forces their hand.
• composer/installers v1 → v2 is a genuinely stalled migration, and this one has no excuse.82% of projects are still on the ^1.0 line: v2.0.0 shipped back in August 2021. Five years on, four out of five plugins in this corpus still haven’t made the jump. If you maintain a Composer plugin, this is probably worth a five-minute check.
• PSR interfaces show the opposite pattern. psr/log, psr/container, psr/http-message all sit around 67–71% latest-major compatibility: no surprise, since these interfaces barely change and a wide ^1.0 || ^2.0 || ^3.0 constraint costs nothing to write.
• Twig and nikic/php-parser are the well-behaved ones — the most-required major is the current major, with 56–78% of projects already on the latest line.

Type: what kind of package is this, really

type is optional, and it shows:

More than a third of the corpus leaves type unset entirely. The default for Composer is to treat it as a library, so the effective library share is closer to 45%. The long tail of one-off types, such as kirby-cms, s9y-core, midcom-package, october-plugin… is a nice reminder of how many CMS-specific plugin ecosystems still route through Composer’s type field for their custom installers.

Minimum stability: how much risk are people willing to take

This is the one that surprised me most. minimum-stability: dev sits at 42.5%: nearly as high as everyone who left the field alone. That’s a huge chunk of the ecosystem explicitly opting in to unreleased, unstable dependency versions by default. It is almost always paired with a prefer-stable: true to soften the blow, though I didn’t check that here. Composer plugins skew younger and more experimental than the average PHP library, and it shows: this is not a community that’s shy about tracking dev-main.

And I don’t think that’s a problem by itself. A component can reasonably stay on dev for as long as it has no real users yet. The moment someone actually depends on it in production is the moment they need a version number to freeze, and not a day before. What’s healthy here is the appetite: a PHP ecosystem willing to try new ideas before they’re polished is a good sign, not a red flag. The gap I keep running into in this data isn’t the experimentation itself, it’s that nothing beyond a handful of leaders, like Symfony, PHPUnit, PHPStan, etc. gets validated by adoption at any scale. Past the top of each list, popularity falls off a cliff, and there’s no real tooling to help a maintainer discover which of the thousands of one-off dependencies in that long tail are actually worth building on. Now that AI makes it trivial to spin up ten experiments where you used to write one, that discovery problem only gets bigger. The bottleneck stops being “can I build this” and becomes “how would anyone downstream ever find out it’s good”.

Corpus: 3052 valid composer.json files scanned across 3285 project directories. Version comparisons pulled live from Packagist at the time of writing: check the linked package pages for current numbers, since this particular table will age fast, by design.