Symfony Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for JSON→DTO mapping. This is glue, not a platform. It wires json-mapper/json-mapper into Symfony's service container so services can receive a configured mapper via DI instead of hand-constructing it. The real buy decision is the underlying JsonMapper library; this bundle just removes ~50–150 lines of bootstrap code and a compiler pass.
• Roadmap: retiring hand-rolled hydration. If your backlog contains "parse this webhook payload," "consume this queue message," or "call this third-party API and get typed objects," attribute-driven mapping converts those from bespoke foreach/isset blocks into declarative DTOs. That is a velocity and defect-rate play, not a feature play.
• Use cases where it earns its keep: inbound webhooks and partner APIs with unstable schemas, Symfony Messenger consumers deserializing to domain objects, typed configuration payloads, and anti-corruption layers in front of legacy arrays. In each, typed DTOs at the boundary shrink the blast radius of schema drift.
• Explicitly not a differentiator. Zero stars and zero dependents mean no community validation and no ecosystem gravity. Do not put it on a roadmap slide as an architectural choice; frame it as an implementation detail that any engineer could replace in a sprint. Budget roughly 1–2 engineer-days for integration and Symfony-version compatibility testing, and treat adoption as reversible.
• Opportunity signal is low (17), and that is itself a decision input. It suggests either a solved problem (Symfony Serializer, JMS, Valinor) or a niche library whose users wire it manually. Either way, the bundle's marginal value over composer require json-mapper/json-mapper plus a small factory service is thin — which caps how much political capital it is worth spending.

When to Consider This Package

Adopt only when all of the following hold:

• You are on Symfony and PHP 8+, and you have already decided JsonMapper is the right mapper for your DTOs (attributes, constructor mapping, no full serializer/validator stack).
• You want container-managed mapper instances — per-service configuration, custom handlers, or JsonMapperInterface autowiring — and you would otherwise write that wiring yourself.
• The surface area is bounded: a handful of integration points where a weekend-scale fork is an acceptable fallback.

Look elsewhere when:

• You have a small number of DTOs. Instantiate the mapper directly; the bundle adds a dependency without adding capability.
• You need maintained, security-reviewed dependencies. Last release 2023-04-04 and no dependents means no downstream pressure to fix compatibility. Verify the symfony/* version constraint against your current Symfony release before committing; the composer solver is your only source of truth here.
• You want batteries included. Symfony Serializer (with #[SerializedName] and denormalization) or cuyz/valinor (typed hydration with validation and excellent error paths) cover more ground with first-party or actively maintained support. If validation-on-hydration matters, Valinor is usually the stronger PM-level answer.
• You need a support contract or SLA. MIT and unmaintained means you own the risk. If it becomes load-bearing, fork it, vendor it under your org, and name an owner.

Bottom line: this is a convenience wrapper. Consider it, don't standardize on it.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed convenience library that lets our Symfony services turn JSON into typed objects without hand-written parsing code. Cost is near zero and the change is reversible. The caveat is maturity: no measurable community adoption and no release since April 2023, so it should not become critical infrastructure without an internal owner. Recommendation: pilot in one bounded service, measure the reduction in mapping code and payload-parsing bugs, then decide whether to fork it internally or move to a maintained alternative such as Symfony Serializer or Valinor.

To engineering: It auto-registers JsonMapper in the container so you can inject JsonMapperInterface and annotate DTOs instead of writing array-juggling in controllers and message handlers. Typed objects at every boundary means IDE completion, static analysis, and failures that surface at deserialization rather than three layers deep. It is a thin wrapper — if the Symfony constraint breaks, we fork it in an afternoon. Do not adopt it for two DTOs; just instantiate the mapper.