Open-Sourcing Our Composer Vendor Checker

The longest phase of any Magento version upgrade is rarely PHP compatibility. It is the vendor audit.

On a recent Magento Commerce upgrade — 2.4.5 to 2.4.8 — we had 30-plus third-party modules to assess. For each one, the question was the same: is there a version compatible with PHP 8.3 and Magento 2.4.8, and if so, where do I get it? The answers lived in five different places: the module vendor's own website, their private Composer repository, Packagist, a client-specific Satis instance, and occasionally a support ticket with a manual download link. Composer's built-in outdated command covers packages registered on Packagist. Enterprise Magento stacks are not primarily Packagist stacks. You get maybe a third of the way there and then you are back to tabbing through browser windows.

We started writing scripts. Then we turned those scripts into a proper Composer plugin. Then we put it on Packagist.

This is that story.

Why composer outdated is not enough

composer outdated asks Packagist (and any repositories listed in your composer.json) whether a newer version exists. For a standard PHP project, that is sufficient. For a production Magento 2 store running Amasty, Aheadworks, MageWorx, XTENTO, and a handful of other commercial vendors, it falls short in two ways.

First, many commercial Magento extensions are distributed through private Composer repositories — the vendor runs their own Satis or repository server, authenticated via project licence keys. These are listed in your composer.json under repositories, but composer outdated does not scrape the vendor's website to tell you what the current public release actually is. It tells you what is in the repository you have access to. If your licence is expired or if the vendor has published a newer release that requires a key upgrade, you may not see it.

Second, some vendors publish version information on public web pages but do not maintain a Packagist listing at all. Checking them means visiting the page, parsing a version string from somewhere in the HTML, and comparing it against what you have installed. Nobody wants to do that for 30 modules by hand.

What we built

qbdigitalsoftware/composer-vendor-checker is a Composer plugin — not a Magento module — that runs wherever Composer runs. Install it into a project and it adds a vendor:check command.

When you run it, it checks every tracked package against up to three sources in parallel, using Guzzle async promises:

1. Vendor websites — public version pages, scraped with bespoke regex patterns per vendor
2. Packagist — but only for packages you have explicitly listed, so it does not hammer the API indiscriminately
3. Private Composer repositories — auto-detected from your composer.json, authenticated via auth.json, with support for V2 p2/, V1 p/, full packages.json, and Satis provider-includes with hash-based URL resolution

Each result comes back with a source field so you know whether the version came from a website scrape, Packagist, or a private repo. The status for each package is one of three things: current, update available, or UNRESOLVED if no check method is configured for it. There is also UNAVAILABLE for cases where the vendor page loaded cleanly but no version string was extractable — which is different from a network failure and tells you something different about what to do next.

For CI/CD integration, the exit codes are explicit: 0 means all packages are current, 1 means updates are available, 2 means there were errors or unresolved packages.

Version 1.0 ships with 29 tracked packages covering Amasty, Aheadworks, Mageplaza, MageWorx, XTENTO, Stripe, Klaviyo, Yotpo, TaxJar, AuthorizeNet (paradoxlabs), and a handful of others that come up repeatedly on enterprise Magento projects.

composer require qbdigitalsoftware/composer-vendor-checker
composer vendor:check

Two things that took longer than expected

The XTENTO case is a good example of the kind of detail that separates a working tool from a reliable one. XTENTO's Magento 2 product pages list both Magento 1 and Magento 2 versions. Our original implementation was picking up the M1 version string in some cases — because the regex matched the first version it found in the page, and the M1 entry appeared higher in the DOM. The fix was to implement a version_select: highest strategy with case-sensitive pattern matching that targets the Magento 2 section specifically. Once we understood what was happening, the fix was straightforward. Getting there required reading the page source carefully and writing a targeted test case.

The private repository auto-detection was more involved. Different vendors structure their private Composer repositories differently: some use the modern V2 p2/ endpoint, some still use V1 p/ packages, some expose a full packages.json, and Satis-based repos use provider-includes with hash-based URLs that need to be resolved before you can query them. We support all four. The tool reads your composer.json repositories block, skips repo.magento.com and marketplace.magento.com (which follow their own authentication patterns and are not what we are solving here), and queries whatever private repos remain. If authentication fails, it surfaces an “auth may be expired” message rather than a generic HTTP error — because on a project with a dozen private repos, knowing which specific credentials have lapsed saves time.

We also handle Cloudflare-protected pages cleanly. Some vendor sites sit behind Cloudflare's managed challenge, which means the HTTP response looks superficially like a success but is actually a challenge page. Rather than returning a garbled version string, the tool detects the Cloudflare response via headers (cf-ray, cf-mitigated) with a body marker fallback, and reports “Cloudflare Managed Challenge” as the status. You know what happened. You know why you are not getting a version. That is more useful than silence.

Honest about limitations

v1.0 has three known gaps that are worth stating plainly.

Amasty changed their licence key system on 1 January 2026. Global project keys no longer work; you need valid project-level keys for the specific installation. If your keys are not configured correctly, Amasty resolution will fail. This is an Amasty infrastructure decision, not something we can work around without the right credentials.

MageWorx private repository authentication was expired at the time v1.0 shipped. It is on the list for v1.1.

Aheadworks sits behind Cloudflare, and their private repository format was not fully verified at v1.0. The website check will report a Cloudflare challenge; the private repo check may not resolve reliably.

These are documented in the repository. We would rather be clear about what the tool does not yet do than ship something that fails silently.

Why we are putting it on Packagist now

The original version was an internal tool — namespaced to GetJohn\VendorChecker, written during the upgrade engagement. It did enough to be useful on that project. Cleaning it up into something we would want to maintain publicly meant rewriting the namespace, hardening the error handling, expanding the vendor coverage, and thinking through the configuration model properly. That work happened over a few weeks alongside the upgrade delivery itself.

This is our first public open-source release. It is a small package with a specific purpose, and at the time of writing it has zero installs and zero GitHub stars. We are not announcing a product. We are putting a tool into the commons that we think other Magento engineers will find useful on the same class of problem — upgrading a production store with a long vendor list.

If you are running a 2.4.5 or 2.4.6 store and looking at a 2.4.8 upgrade, or if you just want a faster way to stay on top of third-party module releases, give it a go.

composer require qbdigitalsoftware/composer-vendor-checker
composer vendor:check