Marshaller Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for data-transformation plumbing. This package is thin Laravel glue around gnugat/marshaller: it registers the library as a container service and exposes a gnugat_marshaller tag for registering your own marshallers. That is a decision you can make in an afternoon either way, so the real question is not "should we take a dependency" but "do we want a conventional, container-wired seam for DTO hydration, request-to-domain mapping, or export/serialization transforms, or do we hand-roll it in a service provider." Treat adoption as a code-organization choice, not a platform bet.
• Feature work on ingestion and transformation pipelines. The tag-plus-service pattern means multiple marshallers can be registered and collected, which fits request payload normalization, CSV/API import adapters, and versioned output shaping. If your roadmap has more than one inbound or outbound data shape, a tagged registry is a defensible pattern to standardize on before you accumulate one-off array_map calls in controllers.
• Architecture and boundary decisions. Where transformation lives — controller, form request, domain service, or a dedicated marshaller layer — is a decision this package nudges you toward by making marshallers first-class, injectable, and testable in isolation. That is worth an explicit call in design review rather than letting it emerge by accident.
• Dependency and maintenance policy. The release pins to gnugat/marshaller v1.0, the library's first stable tag. That is a genuine stability signal, but it is a small, single-maintainer ecosystem component. This should feed your dependency-approval checklist and your bus-factor register, not just the feature backlog.
• Not a roadmap driver. Nothing here changes product scope. There is no new capability in this release — only registration plumbing and a stable upstream pin. Do not let it consume roadmap oxygen.

When to Consider This Package

Consider it when:

• You are already Laravel-based and want the marshaller available via the container and constructor injection, without writing the binding yourself.
• You have more than one transformation to perform and want a tagged, extensible registry rather than a growing switch statement.
• Your team values explicit, isolated transformation classes that are trivially unit-testable over inline array manipulation.
• You want to consume gnugat/marshaller at its v1.0 stable API rather than tracking a pre-1.0 branch — this release is the first point at which that is a defensible position.

Look elsewhere when:

• You need only one or two simple transformations. A single invokable class or a plain Laravel pipeline is less machinery, and this package buys you nothing your own service provider would not.
• You expect heavy throughput. Benchmark the library's reflection- and matcher-driven resolution before committing to a hot path; a thin glue layer does not make the underlying approach cheap.
• Your organization requires active maintenance, security response SLAs, or broad community support. A minimal integration around a small single-maintainer library will not clear that bar, and you should plan to vendor or fork if you adopt anyway.
• You are not on Laravel. The value here is almost entirely the service provider and tag registration; on Symfony or framework-agnostic PHP, depend on gnugat/marshaller directly.
• You need schema validation, typed property mapping with coercion, or deep object graphs. This is not a serializer or a validator, and it should not be asked to become one.

How to Pitch It (Stakeholders)

For executives (one line): A small, low-risk integration that gives us a standard, testable place to put data-transformation logic — a code-hygiene decision, not a new product capability or a vendor commitment.

For engineering leadership: This release wires gnugat/marshaller v1.0 into Laravel's container — a service definition plus a gnugat_marshaller tag so teams can register and collect multiple marshallers through the container rather than instantiating them by hand. It is additive and non-breaking, and the noteworthy part is the upstream v1.0 pin, which is the first stable API we can depend on with a straight face.

Honest caveats to state up front: This is glue, not a platform. The code is small enough that replacing it later is cheap — which cuts both ways: low lock-in, but also low defensibility if someone asks why we added a dependency for it. The underlying library is small and thinly maintained. Recommend adoption only where we already have a real, recurring transformation need, and keep it contained behind our own interface so a future swap is a one-file change. Approve on the understanding that we are standardizing a pattern, not buying a capability.