Object Mapper Laravel Package

Product Decisions This Supports

• Build vs. buy for the "mapping layer": this package is a data point, not a candidate. Its existence confirms that strategy/control-based mapping is a well-understood design problem, which lowers the perceived risk of building a thin in-house mapper tailored to your own object graph.
• Whether to standardize DTO/hydration conventions at all: supports establishing a single mapping seam (request → DTO → domain → resource) before it's urgent, so future modules stop inventing ad-hoc fromArray() helpers.
• Roadmap sequencing for API versioning, modularization, or a public API: a mapping layer is a prerequisite for all three; evaluating this package forces the team to name that seam early and scope it.
• Spike scope, not sprint scope: a 1–2 day timeboxed read of its strategy/control separation can inform your own interface design (one extension point per mapping strategy vs. per-field overrides).
• Decisions it should not drive: your PHP/Laravel version floor, your DTO validation story, or your dependency inventory. It's a reference architecture, not a vendor.

When to Consider This Package

Adopt only if all of the following hold:

• Your app is pinned to PHP/Laravel versions from the 2021–2022 era with no near-term upgrade path.
• You specifically need pluggable mapping strategies with explicit field-level control, and maintained alternatives don't fit your object graph.
• You are willing to fork and vendor it (MIT permits this) and to own it — budget a named engineer as de facto maintainer.
• Blast radius is small: mapping is confined to a boundary layer, never threaded through domain logic.

Look elsewhere — likely the default — if any of these apply:

• 18 stars and a last release of May 2022 mean no upstream fixes, no PHP/Laravel major-version tracking, and no security response. For a dependency in the request path, that tail risk is unacceptable.
• You need Laravel-native integration (validation, casts, Eloquent, container bindings). spatie/laravel-data covers DTO + validation + mapping with active maintenance; cuyz/valinor covers typed hydration with strong error messages; Symfony Serializer's ObjectNormalizer covers the generic case; mark-gerarts/automapper-plus covers the AutoMapper-style strategy pattern.
• Repository provenance is untraceable in our own evaluation metadata — a supply-chain question you shouldn't have to ask of a mapping helper.
• The mapping is simple enough to hand-write. A 200-line mapper you own beats a three-year-stale dependency for most CRUD-shaped applications.

How to Pitch It (Stakeholders)

Executives: We evaluated a third-party object-mapping library and recommend against adoption. It is MIT-licensed and free, but it has negligible community adoption and no releases since 2022, so it would become an unmaintained dependency sitting in our request path. Declining costs nothing and removes a future forced migration; the alternative — a small in-house mapping layer or an actively maintained library — is low-effort and keeps our upgrade path clean. No procurement, no licensing review, no new vendor.

Engineering: The package's core idea — separating mapping strategy from explicit per-field controls — is worth borrowing even though the package isn't. It's a reasonable reference for the interface design of a thin, owned mapping layer at the DTO boundary. Do not take it as a runtime dependency without a named owner, a fork-and-patch plan, and a test matrix against our current PHP/Laravel versions. Preferred stack: spatie/laravel-data where DTOs and validation overlap, cuyz/valinor for typed hydration, hand-rolled in between.