CPX 2.0 Goes First-Party: Run Any Composer Package Without Installing It

Node developers have had npx for years: run a package's CLI without permanently installing it into your project. PHP never had a real equivalent — until Liam Hammett built cpx, and Taylor Otwell used his day-one keynote at Laracon US 2026 in Boston to announce that it's now laravel/cpx, a first-party package with contributors from across the Laravel team.

What cpx actually does

cpx pint --test

That command runs Laravel Pint without you having run composer require laravel/pint first. cpx installs the package into its own isolated directory — separate from both your project's vendor/ and your global Composer setup — and executes the command from there. Run the same version again later and cpx reuses that cached install instead of redownloading it, while still checking for newer releases as it goes.

This matters for a specific, common annoyance: one-off tools you need occasionally but don't want cluttering your composer.json as a permanent dependency — a one-time migration helper, a linter you're trying out, a package you need for a five-minute script and never again.

What's new in 2.0

A few features stood out in the keynote demo:

• Command aliasing — instead of typing the full package name every time, you can alias cpx pint to a shorter form your team agrees on.
• Local script execution with borrowed dependencies — a standalone PHP script can declare packages it needs without you first setting up a whole project around it; cpx resolves and provides them for that run only.
• Running scripts directly from a GitHub Gist URL — point cpx at a gist and it fetches, resolves dependencies, and executes it, which is a genuinely fast way to share a one-off utility with a teammate without publishing a package.

Trying it

composer global require laravel/cpx

cpx laravel/pint --test
cpx nunomaduro/collision

Because cpx isolates each package's install, running cpx laravel/pint in a Laravel 10 project and a Laravel 13 project on the same machine won't clash with each other or with your global Composer packages — each gets its own sandboxed dependency tree.

Why first-party matters here

Community tools solving this kind of gap are common in the PHP ecosystem, but they tend to stay niche without broader backing. Folding cpx into laravel/cpx with direct involvement from the Laravel team gives it the kind of long-term maintenance and visibility that a lone-maintainer package often struggles to sustain — and signals that "run this Composer package without committing to it" is a workflow the framework's stewards consider worth supporting directly, not just tolerating as a third-party convenience.

If you've ever run composer require some/package --dev for a tool you used exactly once and then had to remember to remove it later, cpx is worth adding to your global toolbox.