PHP 8.5's Pipe Operator vs Laravel Collections: Where Piper Fits (And Where It Doesn't)

Originally published at hafiz.dev

PHP 8.5 shipped the pipe operator in November, and most Laravel developers shrugged. Why would we care about |> when collect()->filter()->map() has read top-to-bottom for a decade? Chained transformations are a solved problem in Laravel.

Then Spatie released Piper last month: a library that ports Laravel's collection and string helpers to standalone functions built specifically for the pipe operator. When the team that maintains 300+ Laravel packages decides the pipe operator needs a Laravel-flavored toolkit, the question stops being academic. Is there an actual reason to write $array |> filter(...) |> map(...) instead of reaching for Collections?

I dug into the package, the design decisions behind it, and where each approach actually wins. Short answer: Piper isn't a Collections replacement and doesn't try to be. But there are two specific situations where it's the better tool, and one hard constraint that decides everything before style ever enters the picture.

A 60-Second Pipe Operator Refresher

The pipe operator takes the result of the left expression and passes it as the single argument to the callable on the right:

$result = '  laravel  '
    |> trim(...)
    |> strtoupper(...);

// "LARAVEL"

Each step reads in execution order, top to bottom, no nesting, no intermediate variables. The (...) syntax is PHP 8.1's first-class callable notation.

The catch: the right side must be a callable that accepts exactly one argument. And PHP's standard library was not designed for that. Argument orders are famously inconsistent (array_map($callback, $array) but array_filter($array, $callback)), so half the stdlib needs wrapping in arrow functions before it pipes. That friction is exactly the gap Piper fills.

What Piper Actually Does

Piper (v1.0, requires PHP 8.5) ports Laravel's array and string helpers to namespaced functions under Spatie\Piper\Arr and Spatie\Piper\Str. The design trick: every function is a higher-order function. Calling filter(fn ($i) => $i % 2 === 0) doesn't filter anything. It returns a closure waiting for the one value the pipe will feed it:

use function Spatie\Piper\Arr\{filter, map, join};
use function Spatie\Piper\Str\{prefix, suffix};

$summary = [1, 2, 3, 4, 5, 6]
    |> filter(fn (int $i) => $i % 2 === 0)
    |> map(fn (int $i) => $i ** 2)
    |> join(', ', ', and ')
    |> prefix('The winning numbers are ')
    |> suffix('.');

// "The winning numbers are 4, 16, and 36."

Notice what's absent: no collect() going in, no ->all() or ->toString() coming out. Plain arrays and strings flow through plain functions. That's the entire philosophy.

Where Piper Beats Collections

Native values in, native values out. Collections are a wrapper object. You pay a conversion at each boundary: collect($array) to enter, ->all() to leave, and every method returns a new Collection instance along the way. In application code you barely notice. In code that interfaces with anything expecting plain arrays (third-party SDKs, array-typed signatures, JSON boundaries), the wrapping and unwrapping is pure ceremony. Piper skips it entirely: each function takes an array, returns an array.

Mixing your own functions into the chain. This is the pipe operator's structural advantage, and it's something Collections can't do cleanly. A Collection chain can only call methods that exist on the Collection class (or macros you register globally). A pipe chain accepts any callable: Piper helpers, native functions, your own domain functions, all in one flow:

use function Spatie\Piper\Arr\{filter, map};

$total = $orders
    |> filter(fn (Order $o) => $o->isPaid())
    |> map(fn (Order $o) => $o->total)
    |> array_sum(...)
    |> $this->applyDiscount(...);

With Collections, applyDiscount() either becomes a macro, a ->pipe() call, or a break out of the chain into a variable. The pipe operator treats your functions as first-class chain citizens.

No framework dependency. Piper's functions are standalone with zero Illuminate packages required. For package authors who want Laravel-style ergonomics without pulling illuminate/collections into their dependency tree, that's a real selling point.

Where Collections Still Win

API surface. Piper v1 ports the most-used helpers. Collections have 100+ methods refined over a decade: groupBy(), pluck() with dot notation, chunk(), zip(), mapWithKeys(), higher-order messages like ->map->title, and on and on. The moment your transformation needs one of the deeper methods, you're back in collect() territory, and splitting one pipeline across both styles is worse than picking one.

Lazy evaluation. LazyCollection processes large datasets (cursor results, big files) one item at a time with constant memory. Piper has no lazy story: each function in the chain materializes a full new array. For query results you've already optimized, chaining five Piper functions over 100,000 rows allocates five intermediate arrays.

Eloquent integration. Query builders return Collections. Relations return Collections. Every Laravel API hands you a Collection already. Converting to a plain array just to pipe it through Piper means swimming upstream against the entire framework.

Discoverability. Type -> after a Collection and your IDE lists every available method. With Piper you need to know the function exists, import it, and keep your use function block tidy. It's a small tax, but it's paid on every file.

The Constraint That Decides Everything

Piper requires PHP 8.5. That's not a style consideration, it's a hard gate. PHP 8.5 shipped in November 2025, and most production fleets I see are still on 8.2 through 8.4. If your servers aren't on 8.5, this entire discussion is theoretical, and I'd guess that covers the majority of Laravel apps in production today. I wrote about this lag pattern before: PHP 8.4 features were still "new" to most codebases a full year after release.

There's a second adoption headwind worth naming: AI coding assistants. Sebastian De Deyne (who built Piper) observed that coding agents essentially never produce pipe operator code unless explicitly asked. Training data has a decade of collect() chains and almost no |>. In 2026, syntax that your tooling doesn't reach for by default spreads slower, regardless of merit.

My Take

Use Piper when you're writing framework-agnostic code (packages, shared libraries) or transformation-heavy code on native arrays and strings where pulling in Collections feels like overkill. The function-mixing capability is the one place the pipe operator is structurally better than method chaining, not just different. It's the same kind of decision-tree thinking I apply to services versus actions: pick by code context, not by what's newest.

Inside a Laravel app, keep using Collections. They're everywhere, your team knows them, Eloquent hands them to you, and the lazy variant handles scale. Piper isn't trying to dethrone them; it's filling the gap for the code that lives between Laravel projects. Spatie has a habit of shipping packages a few years before the ecosystem catches up (Scotty did this for deployment), and Piper reads like a bet on where PHP code style lands by 2028, not a tool you must adopt this sprint.

FAQ

Does Piper replace Laravel Collections?

No, and Spatie doesn't position it that way. Piper covers array and string transformations on native values. Collections remain the richer, framework-integrated tool. Think of Piper as a companion for the places Collections are awkward, not a successor.

Can I use the pipe operator with Collections directly?

Not meaningfully. Collections are objects with chained methods, and the pipe operator wants single-argument callables. You could pipe into collect(...) to enter Collection-land, but at that point just use the Collection chain.

Does the pipe operator perform better than Collection chaining?

Marginally, in theory: plain function calls skip the object method dispatch and per-step Collection instantiation. In practice the difference is noise compared to your database queries. Don't pick either approach for performance; pick for readability and context.

Can I use Piper in Laravel 13?

Yes, as long as your runtime is PHP 8.5 or higher. The package has no framework dependency, so it works in any PHP 8.5 project, Laravel or not. The version check that matters is your PHP binary, not your Laravel version.

What about Stringable for string chains?

Laravel's Str::of() fluent strings cover the same ground as Spatie\Piper\Str inside a Laravel app, with the same trade-offs as Collections: wrapper object, framework dependency, huge API. The same logic applies: Stringable in app code, Piper in framework-agnostic code.

Wrapping Up

The pipe operator is the most interesting thing to happen to PHP syntax in years, and Piper is the first serious attempt to make it ergonomic for the Laravel crowd. But interesting and necessary aren't the same thing. If your production PHP is 8.5 and you write package code or work with native arrays at framework boundaries, Piper earns a spot in your composer.json. For everything else, collect() isn't going anywhere.

If you're modernizing a Laravel codebase and weighing which PHP 8.5 features are actually worth adopting, let's talk.

推荐订阅源

DEV Community