Doctrine Laminas Hydrator Laravel Package

Product Decisions This Supports

• Build vs. buy (legacy Laminas/Mezzio services only). This is glue code: Doctrine-aware hydrators that let you map Doctrine ORM entities to and from plain arrays using laminas/laminas-hydrator. The buy case is "don't write ~100–300 lines of custom hydration glue plus strategy classes." The build case is strong precisely because that's all it is — a small, replaceable adapter.
• Feature decisions around data import/export and API shaping. It makes bidirectional entity ↔ array mapping a first-class capability: CSV/ETL ingestion, admin bulk-import tools, and serializing Doctrine entities into JSON payloads without hand-rolled mappers.
• Architecture decisions on DTO layering. If a service needs a clean boundary between persistence entities and transport/API shapes, this reduces the cost of introducing DTOs rather than leaking entities into controllers.
• Explicitly not a Laravel decision. Despite the framing, this is a Laminas-specific integration. For a Laravel codebase the equivalent decisions are already covered by Eloquent API Resources, attribute casting, spatie/laravel-data, or Symfony's ObjectMapper on the Symfony side. Pulling Laminas Hydrator into Laravel means a second, redundant mapping abstraction and an extra framework lineage in your dependency graph.
• Roadmap signal is weak. 37 stars, 0 dependents, and a release dated 2026-10-30 (a future/scheduled tag worth verifying) indicate a maintenance-side package for Doctrine's own Laminas integration, not an ecosystem standard. Treat it as a tactical dependency at most.

When to Consider This Package

Adopt when:

• You maintain a Laminas (Zend Framework lineage) or Mezzio application already using Doctrine ORM.
• laminas/laminas-hydrator is already in the stack, or you have an approved plan to standardize on it.
• You need strategy-driven mapping — naming strategies, nested hydration, collection handling, association/reference hydration — and repeated hand-written mappers are becoming a maintenance cost.
• You want the Doctrine-maintained variant rather than an in-house adapter, and you can accept a small dependency.

Look elsewhere when:

• The codebase is Laravel. Use API Resources, casts, or spatie/laravel-data. There is no product justification for adding Laminas components to a Laravel app.
• The codebase is Symfony or framework-agnostic. Use Doctrine bundle plus Symfony Serializer or symfony/object-mapper.
• You are not already on Laminas. Adopting a framework component solely to get hydrators inverts the dependency direction and creates lock-in for marginal gain.
• Community validation matters to your risk model. Zero dependents and low stars mean you are effectively the first adopter; budget for reading the source and owning fixes.
• Your mapping needs are simple (flat arrays, a handful of entities). A small in-house mapper is cheaper than a new dependency and its upgrade path.

How to Pitch It (Stakeholders)

To executives: A free, MIT-licensed glue library that removes boilerplate when moving data between our database entities and API/import formats — but only for services on the Laminas stack. It is a low-cost tactical dependency with little community adoption, so it carries low upside and modest maintenance risk. Recommended action: no company-wide mandate; evaluate inside the one legacy service where it applies.

To engineering: Doctrine's hydrator adapters for laminas-hydrator — standard strategies, one less set of bespoke mappers, maintained alongside Doctrine's Laminas integration. The trade-off is framework lock-in and a thin user base (0 dependents), so we treat it as replaceable glue and keep our mapping behind our own interfaces. Not for new Laravel work — use API Resources or spatie/laravel-data there.

The ask: A 1–2 day spike in the Laminas service to measure boilerplate removed versus the cost of ownership. Success = measurable mapper code deleted and no upgrade friction; failure = we keep the in-house adapter and move on.