Why I Use Collection::make() Instead of collect()

Laravel ships with a collect() helper that wraps arrays into Collection instances. It works fine. I used it for years. But at some point I switched every project to Collection::make() and never looked back. Here's why.

The helper hides the class

When you write collect(), you're calling a global function that returns an Illuminate\Support\Collection. But you'd never know that from looking at the code. There's no import, no class reference — just a magic function floating in the global scope.

// Where does this come from? What does it return?
$names = collect(['Alice', 'Bob', 'Charlie']);

Compare that with the explicit version:

use Illuminate\Support\Collection;

$names = Collection::make(['Alice', 'Bob', 'Charlie']);

Now you know exactly what class you're working with. The import is right there at the top of the file.

IDE support is better

Most IDEs handle Collection::make() better than collect(). PHPStorm and VS Code can resolve the static method to the class, offer accurate autocompletion on the returned instance, and let you click through to the source. The collect() helper works too with proper stubs, but you're relying on a layer of indirection that the IDE has to figure out. With the static call, there's nothing to figure out.

Consistency with the rest of Laravel

Laravel is full of expressive static constructors. You write Carbon::now(), Str::of(), Http::get(), and Collection::make() fits right in. It follows the same pattern: class name, static method, done. Once you adopt this style, your code reads consistently from top to bottom.

use Illuminate\Support\Carbon;
use Illuminate\Support\Collection;
use Illuminate\Support\Str;

$now = Carbon::now();
$slug = Str::of($title)->slug();
$items = Collection::make($array)->filter()->values();

No helpers, no guessing. Every object creation follows the same shape.

Lazy collections too

The same logic applies to lazy collections. Instead of the undiscoverable LazyCollection helper (there isn't even one built in), you just use the class directly:

use Illuminate\Support\LazyCollection;

LazyCollection::make(function () {
    yield from readHugeFile();
})->each(fn ($line) => process($line));

The counterargument

Yes, collect() is shorter. Yes, every Laravel developer knows what it does. And no, using the helper is not wrong. Laravel's helpers exist for convenience, and if you prefer brevity, collect() is perfectly fine.

But in a team setting — or across multiple projects — I've found that the explicit style scales better. New developers see the import and immediately understand the type. Static analysis tools have less to infer. And the codebase looks like it follows one consistent pattern rather than mixing class calls with global functions depending on which helper exists.

Enforcing it with Rector

If you want to enforce this across a project, Rector can automatically rewrite collect() calls to Collection::make():

use Rector\Config\RectorConfig;
use Rector\Transform\Rector\FuncCall\FuncCallToStaticCallRector;
use Rector\Transform\ValueObject\FuncCallToStaticCall;

return RectorConfig::configure()
    ->withConfiguredRule(FuncCallToStaticCallRector::class, [
        new FuncCallToStaticCall(
            'collect',
            'Illuminate\Support\Collection',
            'make',
        ),
    ]);

Run it once across your codebase and you're done. Every collect() becomes Collection::make() with the proper import added.

It is a small thing

This isn't a hill worth dying on. But small conventions compound. If you're already using Carbon::now() instead of now(), and Str::of() instead of str(), then Collection::make() is just the next logical step. Try it for a week. You probably won't go back.