I thought WordPress dependency management had gone quiet for good. WPackagist sat under every build for about ten years and nobody had a reason to look at it. Then it changed hands, and a tool you never think about becomes a tool you have to think about. WP Packages is not really a protest against the acquisition. It is the rewrite the ecosystem needed anyway.
If your CI pipelines crawl and dependency resolution feels stuck in 2013, that is the part WP Packages goes after. Ben Word and the Roots team built it as a community-funded repository, and it drops the legacy “provider-includes” approach that has been slowing everyone down.
Where WPackagist loses the time
WPackagist makes Composer pull large index files before it can start resolving anything. A cold resolve of a handful of plugins can take over 12 seconds. Its update cycle runs about 90 minutes too, which is a long wait when you need a security patch in your repository.
WP Packages speaks the Composer v2 metadata-url protocol, so Composer only fetches metadata for the packages you actually require. Ten plugins resolve in 0.7 seconds instead of 12.3, a 17x difference. Once your builds sit in that range, package management performance stops being the thing you blame for slow deploys.
What is different under the hood
- Metadata-URL protocol: Composer pulls only the package files it needs, so memory use stays low.
- Immutable caching: per-package files are content addressed and served with public cache headers.
- Cleaner naming:
wp-plugin/andwp-theme/instead of the longerwpackagist-plugin/prefix. - Author data: plugin authors, descriptions and homepage URLs are included, which WPackagist has left out for years.
None of this is exciting on its own, but it takes friction off every build on the team, whether you are shipping a plain site or a custom WordPress AI architecture.
How to migrate to WP Packages
The switch is small. There is a migration script, or you can edit composer.json by hand. I go by hand, mostly so I can see what legacy junk I am leaving behind.
Drop the old WPackagist repository and point Composer at the new one:
composer config --unset repositories.wpackagist && composer config repositories.wp-packages composer https://repo.wp-packages.orgThen update your requirements to the new naming convention:
"require": {
"wp-plugin/akismet": "^5.0",
"wp-theme/twentytwentyfive": "^1.0"
}With dozens of plugins in the file, hand editing gets old fast. The Roots team ships a migration script for that:
curl -sO https://raw.githubusercontent.com/roots/wp-packages/main/scripts/migrate-from-wpackagist.sh && bash migrate-from-wpackagist.shIf this kind of cleanup is eating your week, I can take it off your hands. I have been working with WordPress since the 4.x days.
A win for open source integrity
Transparency is the point of WP Packages. The application code, the build process and even the Ansible deployment config are public on GitHub. That means the ecosystem no longer depends on one company’s goodwill or its marketing plans for the year. Developers built it for developers, which is how this was supposed to work in the first place.
