Data Transformer Bundle Laravel Package

Getting Started

1. Install both packages — the bundle only wires the library into Symfony's container, so you need the underlying library too:

   composer require weblabel/data-transformer-bundle weblabel/data-transformer
   

2. Register the bundle in config/bundles.php:

   Weblabel\DataTransformerBundle\WeblabelDataTransformerBundle::class => ['all' => true],
   

3. Look first at vendor/weblabel/data-transformer-bundle/src/DependencyInjection/ for the extension (what config keys exist, which tags get registered) and Resources/config/ for the service definitions. The README of the underlying weblabel/data-transformer package is where the real API lives — the bundle is just a Symfony glue layer.
4. First use case: inject the transformer registry/manager into a service and convert an incoming payload (array from a controller, JSON from a message, or a row from a repository) into a typed DTO, or the reverse. This is the typical reason to reach for a data-transformer bundle: keeping mapping logic out of controllers and models.

   public function __construct(private DataTransformerInterface $transformer) {}
   public function __invoke(array $payload): MyDto {
       return $this->transformer->transform($payload, MyDto::class);
   }
   

Implementation Patterns

• Autowire the manager, not individual transformers. Register a custom transformer as a service, tag it (e.g. weblabel.data_transformer.transformer — verify the exact tag in the bundle's CompilerPass), and let the registry collect it. Autoconfigure this tag in config/services.yaml so new transformers "just work".
• One transformer per direction. Most implementations of this style have transform($input): mixed and sometimes reverse(...). Keep each transformer small and single-purpose (e.g. AddressTransformer, MoneyTransformer) rather than one giant mapper — it makes caching and unit testing trivial.
• Chain via tagged iterators. If the package collects transformers by priority/supports(), use that to build per-field pipelines:

  App\Transformer\AddressTransformer:
      tags: [{ name: 'weblabel.data_transformer.transformer', priority: 10 }]
  

• Integrate with Symfony Serializer for nested cases. Use the bundle for the top-level object graph, and lean on Serializer/ObjectNormalizer attributes (#[SerializedName], #[Groups]) for leaf nodes rather than re-implementing normalization.
• Wire into Messenger and Console commands the same way you would any service — the primary win of the bundle is that transformations stop being static helper calls sprinkled across controllers and become injectable, mockable collaborators.
• Form data transformers are not this — don't try to reuse this bundle for Symfony Form\DataTransformerInterface; they share a name but not a contract.

Gotchas and Tips

• Abandonware risk. Last release December 2021 and zero dependents means no Symfony 6.x/7.x guarantees. Run composer why-not weblabel/data-transformer-bundle after upgrading Symfony; you may need to add symfony/deprecation-contracts and patch getContainerExtension() signatures, or fork it.
• Tag names are the whole integration. If transformers aren't being picked up, the tag string in your services.yaml doesn't match what the bundle's compiler pass collects. Debug with php bin/console debug:container --tag=<tag> — if your service isn't listed, the tag name or autoconfigure rule is wrong.
• Config tree is strict. The extension likely defines a Configuration class; misspelled keys in config/packages/weblabel_data_transformer.yaml throw at cache warmup. Start with an empty config block and let validation errors show you the valid keys.
• The bundle is thin — the bugs are usually in the library. When a transformation goes wrong, the stack trace will almost always point into vendor/weblabel/data-transformer/, not the bundle. Read that package's source and tests; the bundle source is small enough to read in one sitting.
• Type juggling at the boundaries. Data transformers that accept mixed will happily swallow strings where you expected arrays (or vice versa). Add a supports() guard or an assertion at the boundary, and give each transformer a unit test with the exact shape of input you receive from Symfony (Request query params are strings, Messenger payloads are arrays, entity getters return objects).
• Extension points to prefer: custom transformer services and (if present) the bundle's tag for registering them. Avoid extending bundle internals — with zero downstream users the BC surface is unmaintained, so subclassing anything under Weblabel\DataTransformerBundle\ is a foot-gun.
• Consider the opportunity cost. For a Laravel codebase bridging into Symfony, or for greenfield Symfony work, symfony/serializer + symfony/property-info + explicit DTOs gives you the same "transform data cleanly" outcome with an actively maintained dependency. Reach for this bundle only if you're already committed to the weblabel/data-transformer API.