Easy Hydrator Laravel Package

Product Decisions This Supports

• Build vs. buy (data mapping): Decides whether your team writes its own array→object hydrator or adopts an existing one. This package is a buy/borrow candidate that has been formally sunset, so it mainly supports the decision to build small or buy maintained rather than to adopt this dependency.
• Roadmap: request/response DTO layer. Informs planning for typed DTOs at the edges of the app — form requests, API payloads, webhook bodies, queue job payloads, config/array → value object mapping. These are the exact use cases constructor-injection hydration serves.
• PHP version modernization. The package's PHP 7.4 framing makes it relevant to a 7.4 → 8.x upgrade decision: it either becomes a migration blocker or a small piece of debt to retire in the same sweep.
• Vendor/dependency risk register. Zero dependents, zero stars, and a deprecated-packages upstream are strong signals for the dependency review board — a "do not add" entry and, if already present, a scheduled removal.
• Framework consolidation. Whether to lean on first-party/Laravel-native or Symfony components already in the stack instead of adding a narrow, unmaintained helper.
• Opportunity signal: the low opportunity score (19.54) matches the near-zero adoption — there is no ecosystem pull here, so no strategic upside in standardizing on it.

When to Consider This Package

Consider it only in narrow, non-strategic contexts:

• A legacy PHP 7.4 codebase already depends on the broader Symplify toolchain and you are not adding new surface area.
• Throwaway internal tooling, one-off scripts, or a demo where the dependency will never be maintained or audited.
• You are explicitly vendoring or forking it (it is MIT-ish permissively licensed in most such packages — verify) and accepting ownership of that fork.
• You need a reference implementation to show engineers the constructor-injection hydration pattern before writing ~100 lines of your own.

Look elsewhere when any of the following is true — which is most of the time:

• Maintenance matters (production, multi-team, long-lived). The upstream is archived/deprecated: no security patches, no PHP 8.x support guarantees, no issue triage.
• Adoption risk matters. Zero stars and zero dependents means no community validation, no Stack Overflow answers, no third-party bug reports. You will be the only person running it in anger.
• Better-maintained alternatives exist and are already in your stack: Symfony Serializer (often already present), cuyz/valinor, spatie/laravel-data (for Laravel DTOs), Laravel's own validation + FormRequest, or plain constructors with named arguments in PHP 8+.
• You need advanced mapping — nested objects, collections, type coercion, attribute-based mapping, enum handling, circular references. A thin constructor-injection hydrator will not cover it.
• Compliance or audit requirements apply (SOC2, procurement review) — an archived dependency will not survive a security questionnaire.
• Simple cases. If you only need to map a handful of arrays, a static factory method or new Foo(...$payload) with named arguments is cheaper than any dependency.

How to Pitch It (Stakeholders)

To executives (30 seconds): This is a small PHP utility that turns arrays into typed objects using constructor injection — the plumbing behind clean API and form handling. It is archived upstream, has no adopters, and carries no strategic upside, so my recommendation is not to adopt it and, if we already use it, to schedule removal during the next PHP upgrade. Cost of the alternative is low: equivalent functionality exists in components we already pay for, or is a few dozen lines of code we control.

To engineering leadership: Treat symplify/easy-hydrator as a sunset dependency. It solves a real problem — array → typed object mapping at application boundaries — but it is no longer maintained and gives us no leverage. The pattern is trivially reproducible and the maintained options (Symfony Serializer, spatie/laravel-data, cuyz/valinor) are already familiar. Recommendation: do not add it to new code; add a ticket to replace it where it exists. Migration cost is low because the surface area is small and the call sites are concentrated at input boundaries.

To the engineering team: No new dependency. If you want the ergonomics, either use named-argument constructors and a small static fromArray() factory, or pick one maintained mapper and standardize on it. If you must keep this package for legacy reasons, isolate it behind our own Hydrator interface so the swap is a one-file change next quarter.