Auto Mapper Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy on the mapping layer. Every product with more than one representation of the same domain object (entity ↔ DTO ↔ API payload ↔ webhook/CRM shape) eventually writes a mapper. This package is a candidate "buy" for that layer: MIT-licensed, small surface area, attribute-driven configuration. The decision it informs is not "should we map objects" — that's settled — but "do we hand-roll ~300 lines of per-entity mapping, or adopt a declarative mapper and take on a dependency."
• API contract stability and versioning. Auto-mappers encourage an explicit transport model, which lets you version a public API or partner integration (e.g. an order/customer payload) without touching persistence models. That directly supports roadmap items like "add a second sales channel" or "expose a partner API," where the cost is usually not the endpoint but the N×M translation code behind it.
• Integration-heavy roadmap bets. RetailCRM's own domain is order/customer sync across channels — the package's design assumptions reflect that. If your roadmap includes CRM, ERP, or marketplace connectors, this is a reasonable reference architecture even if you don't adopt the code.
• Refactor scoping and tech-debt sizing. Presence of a mapper abstraction lets you estimate "decouple Eloquent/Symfony entities from API responses" as a bounded task instead of a rewrite. Useful for sequencing work against a deadline.
• Make-vs-integrate for platform choice. Because this ships as a Symfony bundle, it is effectively a point in favor of Symfony over Laravel for teams that are otherwise neutral. That's a platform-level product decision, and it should be made deliberately rather than by accident when this package appears in an evaluation.
• Vendor-risk policy calibration. With 1 star and 0 dependents, this package is a live test case for whatever your dependency-adoption policy actually is. If your policy would accept it, the policy is looser than you think; if it would reject it, you now have a concrete example to cite.

When to Consider This Package

Consider it when:

• Your application is Symfony-based and already uses the framework's DI, service tagging, and configuration conventions — the bundle is doing the wiring work you'd otherwise write.
• You have many similar mapping pairs (dozens of entity↔DTO pairs) where hand-written mappers are a measurable maintenance tax, and you want the mapping declared next to the object rather than in a service class.
• You need to map object graphs (nested collections, associations), not just flat scalar arrays — this is where naive array_map code starts to hurt.
• You are comfortable pinning an exact version, vendoring or forking if needed, and treating the mapper as internal infrastructure rather than a community-supported dependency.
• You want a reference implementation to read before writing your own — MIT license makes this free.

Look elsewhere when:

• You are on Laravel. This is a Symfony bundle; there is no AutoMapperServiceProvider, and adopting it means pulling the underlying retailcrm/auto-mapper library and writing your own container wiring — at which point you are maintaining a fork of the integration layer.
• You need community validation. 1 GitHub star and 0 dependents means no ecosystem signal, no Stack Overflow corpus, no third-party tutorials, and no evidence of production use outside the vendor. Budget for reading the source as your only documentation.
• You have a maintainer-risk constraint. Single-vendor, effectively single-maintainer. If composer audit/license policy gates on bus factor, this fails.
• Mapping is on a hot path. Attribute/reflection-driven mappers trade CPU for declarative config. For high-RPS serialization, benchmark first; often a hand-written mapper or Symfony Serializer with groups wins.
• Your mapping needs are trivial. Two or three DTOs do not justify a dependency; write the fromEntity() methods and move on.
• You need mapping plus validation/casting. If you want DTOs that validate and cast (common in Laravel), spatie/laravel-data covers more of the job in one dependency.
• The release metadata doesn't check out. The listed last release (2026-08-03) is in the future relative to typical review dates — verify tags and changelog before relying on this row from the package index.

How to Pitch It (Stakeholders)

For executives (30 seconds): "This is a small, MIT-licensed library that removes repetitive code translating our internal data models into the shapes our APIs and partners expect. The capability is real and the license cost is zero, but the community footprint is essentially nil — one star, no downstream users — so we would be the first meaningful adopter. My recommendation is not to standardize on it. Instead, approve a one-to-two day engineering spike to evaluate it as a reference design, and keep our current approach as the fallback. The downside is capped at a couple of days of engineering; the upside is a cleaner integration layer for the CRM/partner work already on the roadmap."

For engineering:

• It's a Symfony bundle wrapping RetailCRM's attribute-based auto-mapper. The mapper is the substance; the bundle is DI/configuration sugar. On Laravel, you'd consume the core library and write the wiring yourself — that is the real cost, and it should be estimated honestly.
• Evaluate against: hand-written mappers (zero risk, linear cost), Symfony Serializer with groups, and spatie/laravel-data on the Laravel side. Benchmark reflection-based mapping on your heaviest payload before committing.
• Acceptance criteria for the spike: (1) maps our three most complex payloads without per-field boilerplate, (2) measurable CPU cost on the largest realistic payload, (3) upgrade path if the vendor stops shipping, (4) an exit plan — every adoption decision should name what removing it costs.

Recommendation: Treat as an evaluate-and-borrow item, not an adopt item. High opportunity score, low adoption evidence — the gap between those two numbers is the entire decision, and it should be closed with a timeboxed spike rather than a standards decision.