Serializer Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy on the serialization layer. Every Symfony service with an HTTP API eventually writes a translation layer between PHP objects and JSON. This package is a candidate to buy (well, adopt — Apache-2.0) instead of building, but the decision is not "is it good," it's "is the maintenance we avoid larger than the risk we take on."
• API contract ownership. Attributes (#[Serialize], serializedName, discriminatorMap) become the single source of truth for the wire format. Combined with the auto-registered NelmioApiDocBundle describer, OpenAPI docs are generated from the same metadata that does the (de)serialization — that is a documentation-drift decision, not a code decision. If your roadmap includes public/partner-facing API docs, this materially reduces the support burden of stale specs.
• What a relation looks like on the wire. EntityIdHandler lets you emit author: 42 instead of embedding a full Author object, and hydrate back to an entity on input. That is a product-level API shape decision (IDs vs. nested expansion) that directly affects payload size, mobile/bandwidth budgets, and how much a client must know about your graph.
• Polymorphic payloads. discriminatorMap supports heterogeneous collections in a single endpoint (e.g. a feed of person and machine items). Useful if the roadmap includes mixed-type timelines, activity feeds, or extensible content blocks; otherwise it's unused surface.
• Latency budget on read endpoints. The batch handler interfaces (BatchSerializeHandlerInterface / BatchDeserializeHandlerInterface) collapse per-item lookups into one query per collection. For list endpoints backed by Doctrine relations this is the difference between a 40ms and a 1.2s response — a concrete way to hit a latency SLO without adding a caching tier.
• DTO boundary vs. entity-as-DTO. Because every serialized property needs a public getter/setter and the constructor can't have required parameters, this package nudges you away from readonly/immutable DTOs and toward mutable, setter-driven models. That's an architecture decision your tech lead should own, not something to discover mid-sprint.
• Roadmap shaping for multi-format support. JSON only, explicitly. If your roadmap has CSV export, XML for a partner, or HAL/JSON:API envelopes, you're either building that on top or picking something else.

When to Consider This Package

Reasonable fit when most of these are true:

• You're a Symfony shop, self-contained, and control both the producing and consuming ends of the API.
• Your payloads are DTO/entity-shaped and Doctrine-backed — the EntityIdHandler and batch handlers exist precisely to solve the ID-vs-object and N+1 problems, and they're the main reason to prefer this over Symfony's native Serializer.
• You want OpenAPI docs generated from the same annotations as your serialization, with no second spec to maintain.
• You're comfortable pinning a version and reading the source when behavior is ambiguous — the README is unusually detailed on semantics (batch caveats especially), but there's no cookbook, no migration guide, no issue history to search.
• Your team is small enough that "one library instead of three" has real onboarding value.

Look elsewhere when any of these are true:

• You need a community. 0 stars, 0 dependents, single-vendor. There is no Stack Overflow corpus, no third-party blog posts, and no realistic expectation that a bug you hit has already been fixed by someone else. If your team has no appetite for reading vendor source, stop here.
• You need formats other than JSON. Symfony Serializer or JMS handle XML/CSV/YAML; this doesn't.
• You need stable, versioned public API guarantees. A single-maintainer package with a small dependent base cannot credibly promise semver stability for a partner-facing contract. Vendor risk lands on your roadmap.
• Your models need required constructor arguments or immutable value objects. The getter/setter + no-required-constructor constraint is a hard architectural constraint, not a preference.
• You're already on API Platform or JMS. Both solve this problem plus more; adding a second serializer to the stack is a net negative.
• "Fast & light" is load-bearing in your decision. The claim is unsubstantiated — no benchmarks in the README. Treat it as marketing until your engineers measure it against Symfony Serializer on your actual payloads. If performance is the reason you're looking, make the benchmark a gate.

How to Pitch It (Stakeholders)

For executives: This is a small, free (Apache-2.0) Symfony component that replaces hand-written JSON conversion code and, in doing so, eliminates two recurring costs: API documentation that drifts out of sync with the API, and slow list endpoints caused by per-item database lookups. The trade-off is vendor concentration — it's maintained by a single organization with no external user base — so adoption should be treated as a build-vs-buy bet with a defined exit path, not a default.

For engineering: It's attribute-driven, Doctrine-aware, and the batch handler interfaces solve the N+1-on-serialization problem that Symfony's native Serializer leaves to you. The Nelmio integration gives you OpenAPI for free. The costs are real and specific: JSON only, public getter/setter plus no-required-constructor on every serialized class, and batch semantics with enough caveats (array/Collection only, forced handlers only, idempotency required, singleton state in long-running workers) that they need a test before you rely on them. Pin the version, keep the serializer attributes off your domain entities and on a DTO layer so the dependency stays swappable, and benchmark against Symfony Serializer on a representative list endpoint before committing. If it doesn't win on that benchmark, the only remaining argument is the OpenAPI generation — which is worth having, but not worth a one-way dependency.