Mapper Bundle Laravel Package

Product Decisions This Supports

Honestly assessed: this package should support exactly one decision — a "do not adopt" call, and the reasoning is worth recording so the team doesn't re-litigate it in six months.

• Build vs. buy, resolved toward "build small": The capability it gestures at (mapping domain entities to other representations — DTOs, view models, API payloads) is a 100–300 line concern in most Laravel codebases. A dedicated bundle is only justified when mapping logic is numerous, bidirectional, and configuration-heavy.
• Roadmap de-risking: Last release 2015-10-12, 0 stars, 0 dependents. That is not "low adoption" — it's an abandoned artifact. Zero dependents means zero downstream users stress-testing it, zero issue reports, zero patches. Any roadmap item that depends on it inherits that abandonment.
• Platform-fit check: Despite the framing, this is a Symfony bundle, not a Laravel package. Laravel has no bundle/service-container-extension model that would load it cleanly. That alone removes it from a Laravel roadmap.
• Use-case framing that does survive: the useful takeaway is the pattern, not the code — an explicit mapping layer between persistence models and transport/domain shapes. That can inform a design decision (e.g., adopting spatie/laravel-data or Laravel API Resources) even though the package itself is dead.
• Not a viable spike/reference either: the description ("Linking the different elements") is too vague to establish what it actually does; there's no README signal, no docs, no demo. Evaluating it would cost more than writing the mapper.

When to Consider This Package

Adoption criteria — all would need to be true, and several cannot be:

• Actively maintained within the last ~12 months, with responsive issue triage.
• Laravel-native (service provider, config publishing, container bindings) — fails.
• Compatible with the PHP/Laravel versions on your support matrix — likely fails; a 2015 Symfony bundle targets PHP 5.x-era constraints and Symfony 2.x components.
• Non-trivial community signal (stars, dependents, transitive installs) to justify trusting it in production — fails at 0/0.
• Clear, documented behavior so you can reason about edge cases (nulls, nested collections, circular refs) — fails; the description is one sentence.

When to look elsewhere (i.e., essentially always):

• You need model→DTO mapping in Laravel: spatie/laravel-data for typed DTOs with construction from Eloquent models; Laravel API Resources if the target is purely response shaping.
• You need a maintained, configurable auto-mapper: jolicode/automapper (Symfony ecosystem, actively maintained) or a hand-rolled mapper registry — mapping is one of the few places where explicit code beats magic, because failures are silent.
• You inherited a legacy Symfony 2 app that already depends on it: treat it as frozen. Pin the version, isolate it behind your own interface, and budget a replacement rather than an upgrade.
• You want to read it for design ideas: acceptable, but read jolicode/automapper or spatie/laravel-data instead — same ideas, current idioms, and you can actually ask the maintainers questions.

How to Pitch It (Stakeholders)

For executives — one line: Not recommended. The package is a nine-year-old Symfony bundle with no maintainers, no users, and no documentation; adopting it would mean owning and patching abandoned third-party code to save perhaps a day of work.

For engineering — the substance:

• Wrong ecosystem: Symfony bundle, not a Laravel package. Integration would require adapters or a fork, and the fork becomes ours to maintain forever.
• Supply-chain and security exposure: unmaintained PHP dependencies from the 2015 era are a standing audit finding — no security releases, no CVE response, and transitive dependency drift against modern PHP. Verify the license and any bundled dependencies before it touches a repo, even as a dev dependency.
• Zero support surface: 0 stars, 0 dependents, no issue history. Every bug is our bug, and there's no upstream to escalate to.
• The capability is cheap; the dependency is not: entity↔DTO mapping is a small, well-understood layer. We can implement it explicitly in a sprint, or adopt a maintained library for free.
• Recommendation: reject; record the decision; if mapping is on the roadmap, spike spatie/laravel-data against two real endpoints and compare against hand-written mappers before committing.