Weave Code
Collections Laravel Package
doctrine/collections
Doctrine Collections is a PHP library providing powerful collection abstractions, including ArrayCollection, typed collections, Criteria filtering, expression-based matching, selectors, and iterators for flexible data manipulation.
Doctrine Collections is a standalone PHP library providing a powerful abstraction layer for working with collections of objects. It offers a rich set of interfaces and implementations, including ArrayCollection and Criteria, enabling consistent, type-safe manipulation of data without depending on the full Doctrine ORM.
- ArrayCollection for wrapping and manipulating native PHP arrays
- Criteria for expressive, database-agnostic filtering, ordering and pagination
- Lazy collections for memory-efficient iteration over large datasets
- Rich API with map, filter, slice and other functional helpers
- Fully framework-agnostic and usable in any PHP project
Frequently asked questions about Collections
- Is doctrine/collections compatible with Laravel 11 and 12?
- Yes. Doctrine Collections is framework-agnostic and has no Laravel coupling, so it installs and runs alongside Laravel 11 and 12 without service provider or config changes. The main constraint is PHP version: 3.x requires PHP 8.4, while Laravel projects on PHP 8.2 or 8.3 should pin to the 2.x line.
- How do I install doctrine/collections in a Laravel app?
- Install it with Composer using composer require doctrine/collections. Choose the version that matches your PHP baseline: 2.6 on PHP 8.2 or 8.3, or 3.x on PHP 8.4 and above. No Laravel service provider registration or configuration is needed because the library has no framework hooks.
- Which PHP version do I need for doctrine/collections 3.x?
- Version 3.x of doctrine/collections requires PHP 8.4 and makes all classes final. If your Laravel application runs on PHP 8.2 or 8.3, pin to 2.x, with 2.6 being the last feature line that supports Selectable. Plan the upgrade to 3.x around your PHP baseline, not the other way around.
- Doctrine Collections vs Illuminate\Support\Collection: which should I use in Laravel?
- Use Illuminate\Support\Collection as the default for controllers, Blade views, JSON shaping, and general Eloquent work because your team already knows it. Reach for Doctrine Collections only where you need strict generics for static analysis, reusable Criteria-based filtering, or a path toward Doctrine ORM. Mixing both idioms across services adds cognitive overhead, so introduce it behind interfaces in specific bounded contexts.
- Does doctrine/collections require Doctrine ORM or DBAL?
- No. Doctrine Collections is a standalone in-memory collection abstraction with no runtime dependency on Doctrine ORM or DBAL; the dependency runs the other way, with the ORM depending on the collections library. That makes it safe to add to a Laravel project without pulling in a database layer.
- How do I convert an Eloquent result to a Doctrine ArrayCollection?
- Convert at the boundary with a thin adapter, for example new ArrayCollection($model->toArray()) when handing Eloquent data to a Doctrine-based service and toArray() when returning it. Keep these conversions in one place so neither collection idiom leaks into the other's territory. Presentation and HTTP-adjacent code should stay on Illuminate collections.
- What is the Criteria API in Doctrine Collections used for?
- Criteria and ExpressionBuilder provide a declarative DSL for filtering, ordering, and paginating in-memory collections, and CompositeExpression lets you combine conditions. They are useful when the same filtering logic must be shared across repository implementations, report builders, or spec-style services. For ordinary Eloquent queries, native query scoping is usually sufficient.
- Can I extend ArrayCollection or Selectable in version 3.x?
- In 3.x all classes are final and the extension hooks were intentionally removed, so subclassing ArrayCollection or Selectable is not supported. If you rely on custom subclasses, stay on the 2.x line and plan a refactor toward composition before upgrading. The 3.0 major also removed accessRawFieldValues and tightened return types, which can break loosely typed code.
- Is doctrine/collections safe for production and actively maintained?
- Yes. The project has been released continuously for over a decade, follows semantic versioning, and is exceptionally mature with low technical risk. The real risk is adoption risk inside a Laravel codebase, where a second collection abstraction can complicate onboarding and create inconsistent service return types.
- How do I get static analysis benefits with typed Doctrine Collections in PHPStan or Psalm?
- Annotate properties and return types with @template T and Selectable<T> so PHPStan or Psalm can infer element types across method calls. Version 2.x with Selectable support and native return types in 2.0 and later give the strongest guarantees without requiring PHP 8.4. This static-analysis rigor is the main reason to choose Doctrine Collections over Illuminate collections in a Laravel service layer.
Weaver
How can I help you explore Laravel packages today?