Frontend Mapper Bundle Laravel Package

Product Decisions This Supports

• API contract and DTO design — the underlying idea (mapping PHP domain models into frontend-consumable structures) is relevant to decisions about hand-written serializers vs. generated contracts. The package is a reference for that discussion, not an implementation choice.
• Build vs. buy vs. borrow — this is a "borrow the pattern, build it yourself" input. It is not a viable buy: no maintainers, no release since January 2016, and a health score of 0.01.
• Framework standardization — diligence flag: this is a Symfony bundle, not a Laravel package. Its only legitimate product value in a Laravel context is to surface that mismatch before someone adds it to composer.json by mistake.
• Modernization / technical-debt scoping — if any service already depends on it, that dependency is a modernization line item (PHP 5.x-era code, abandoned upstream), not a feature enabler.
• Use cases it could theoretically inform — legacy Symfony 2.x/3.x admin tooling, one-off prototypes, or archaeology on older codebases. None of these are forward-looking roadmap decisions.

Honest framing: no new feature should be scoped on this package, and no roadmap item should cite it as a dependency.

When to Consider This Package

Adoption criteria — all would have to be true, and in practice none are:

• You are maintaining a legacy Symfony 2.x/3.x application that already ships it.
• Replacement cost exceeds the risk of leaving it in place.
• The dependency is isolated, low-traffic, and covered by contract tests.

When to look elsewhere — effectively always for new work:

• Symfony: Symfony Serializer, API Platform, or JMS Serializer.
• Laravel: API Resources / Eloquent serialization.
• Typed frontend contracts: generate TypeScript from OpenAPI (openapi-typescript, orval) or hand-rolled mappers plus contract tests.

Risk signals a PM should weigh: 2 stars, 0 dependents, score 0.01, last release 2016‑01‑18, no maintenance in roughly nine years, dependencies pinned to PHP 5.x-era constraints, and no security response path.

How to Pitch It (Stakeholders)

• Executives: Not a candidate for adoption. Zero measured adoption, no tagged release in nine years, no active maintainer. Recommendation: no investment; treat as reference-only if it appears in an audit, and budget a small modernization line if any team is already on it.
• Engineering: It is a Symfony bundle, not Laravel. Do not add it as a dependency. If the frontend-mapping pattern is attractive, reimplement it with the framework's native serializer plus generated TypeScript types — a small, testable, maintained surface that we control.
• Product: No user-facing capability is gated on this. It supports no near-term roadmap commitment; the only product-relevant output is a decision to build rather than borrow.