Mapper Bundle Laravel Package

Product Decisions This Supports

• Architecture standardisation: whether we introduce a dedicated mapping/transformation layer between domain models, persistence models, and API resources — or keep hand-writing toArray() / transformer classes per endpoint.
• Build vs. buy on glue code: if we are maintaining in-house entity→DTO mappers, this package is a candidate to replace that internal utility rather than something we build from scratch.
• API contract stability: a mapping layer makes it cheaper to version responses and stop exposing ORM models directly, which underpins decisions about public API deprecation policy.
• Roadmap input for a platform-consistency initiative: adopting one mapping convention across services, or explicitly deciding not to.
• Representative use cases: response shaping for multi-tenant or role-based payloads, integration adapters translating third-party payloads into internal DTOs, gradually decoupling legacy response builders from Eloquent/Doctrine entities.
• Decisions this should not drive: anything requiring vendor commitment, security assurance, or hiring-market familiarity. With 0 stars and 0 dependents, this is an unvalidated single-maintainer artifact, not an ecosystem standard.

When to Consider This Package

Consider it when:

• The team is a small in-house PHP group comfortable reading vendor source and pinning versions.
• The need is narrow and concrete: declarative mapping configuration instead of another dozen bespoke transformer classes.
• We can wrap it behind our own interface so it never leaks into domain code and can be swapped out in a sprint.
• MIT licensing makes fork-and-vendor a genuine mitigation — we can absorb the code if upstream goes quiet.
• The maintenance signal (recent release cadence) matches our near-term window; long-horizon support is not assumed.

Look elsewhere when:

• Framework fit is wrong. The "Bundle" suffix implies Symfony conventions, not Laravel. Verify this before anything else — a Symfony-only dependency is disqualifying in a Laravel codebase regardless of code quality.
• We need a proven option: spatie/laravel-data, Symfony Serializer, or JMS Serializer carry real adoption, documentation, and hiring familiarity.
• We need an SLA, security review, or CVE monitoring — there is no vendor and effectively no user base to surface issues.
• The mapping requirement is trivial; a handful of mappers does not justify a dependency, a fork obligation, and a version-pinning policy.

How to Pitch It (Stakeholders)

For executives: This is a small MIT-licensed utility for standardising how we transform data between our internal models and API responses — a place we currently duplicate logic. Direct cost is near zero and the licence lets us take ownership of the code if needed. The honest caveat is adoption: zero stars, zero dependents, one maintainer. So the ask is not a platform commitment; it is a two-day spike against a real endpoint, with a decision gate. Downside is capped because nothing proprietary is at stake.

For engineering: The proposal is to centralise entity→DTO mapping behind an adapter interface, pin the version, and keep it out of the domain layer entirely. Success criterion: it removes more transformer code than it adds within the spike, and the team can read the whole dependency in an afternoon. Two blockers to check first — the package follows Symfony "Bundle" conventions, so Laravel compatibility needs confirming, and there is no community to fall back on for edge cases. If either check fails or the spike is a wash, we keep our hand-rolled transformers and close the ticket.