Object Mapper Bundle Laravel Package

Product Decisions This Supports

• API / DTO layer design: Informs whether we hand-roll model-to-DTO transformation (e.g., Eloquent model → API resource or response object) or pull in a mapping library. This package targets exactly that “copy state from one typed object to a differently typed object” problem, which surfaces in every Laravel app that separates domain models from transport payloads.
• Build vs. buy for mapping logic: Given the package’s age (last release May 2022), 2 GitHub stars, 0 dependents, and MIT license, the realistic decision it supports is build a small in-house mapper or adopt an actively maintained alternative rather than depend on this one.
• Framework-fit decision (important caveat): This is a Symfony Bundle, not a Laravel package. Laravel has no bundle system, so adoption in a Laravel codebase means either using the underlying opportus/object-mapper library directly or re-wrapping its service provider. That reframes the decision from “adopt this package” to “adopt/vendor this mapping concept.”
• Roadmap signal: Useful as a reference point for how not to mature a mapping utility — it shows the value of mapping strategies and extensible controls, which we can copy into our own internal tooling or a different library’s configuration.
• Use cases it theoretically enables: converting request/command objects into domain models, mapping between legacy and new entity versions during migrations, and normalizing heterogeneous objects into a shared DTO — all real needs, but better served by alternatives in a Laravel context.

When to Consider This Package

• Only in a Symfony codebase where you already follow the bundle registration pattern and need flexible, strategy-driven object mapping (custom mappings for differently-typed properties, extensible transformation controls) without writing bespoke mappers.
• Only as a non-critical, internal convenience — e.g., a side tool, admin utility, or prototype — where a stalled dependency is tolerable and you can fork or vendor the code under MIT if needed.
• When you want a lightweight, unopinionated mapper rather than a full serialization framework, and you can accept reading source for documentation (no meaningful community, no recent releases, minimal support surface).
• When NOT to consider it: Any Laravel project (no bundle support, no dependents to validate compatibility with modern PHP/Laravel versions), any production system with maintenance SLAs, any team that needs security patch cadence or community support, and any case where established, maintained options fit — e.g., spatie/laravel-data, jolicode/automapper, Symfony Serializer, or plain constructor-based mapping in Eloquent resources.

How to Pitch It (Stakeholders)

• For executives: This is a niche object-mapping utility with essentially no adoption (2 stars, 0 dependents) and no updates since 2022. It is technically MIT-licensed and free, but adopting an unmaintained dependency for core data transformation creates long-term maintenance and security-patch risk with no community or vendor to fall back on. Recommendation: do not adopt for production; if object mapping becomes a roadmap need, prefer a maintained library or a small internal implementation we control.
• For engineering: It is a Symfony Bundle, so it does not natively fit a Laravel stack — it would require vendoring the underlying mapper and wiring it manually. The core idea (strategy-based, extensible controls for copying state between differently-typed objects) is sound and worth borrowing; the packaging and maintenance are not. If we need this capability, evaluate jolicode/automapper or spatie/laravel-data first, and treat an in-house mapper of ~100–200 lines as a viable fallback.