Serializer Bundle Laravel Package

Getting Started

Despite living in a Composer ecosystem shared with Laravel, this is a Symfony framework bundle, not a Laravel package. The 3.1.2 release adds Symfony 5 support to an already Symfony-centric dependency set (symfony/framework-bundle, symfony/dependency-injection, symfony/twig-bundle, doctrine/orm). Before adding it:

• Confirm you actually have a Symfony application to drop it into. There is no Laravel service provider here — the wiring target is Symfony's AppKernel (3.x/4.x) or bundles.php (4.x+), plus config/bundles.php in Symfony Flex projects.
• Run composer require <vendor>/<package>:^3.1 and check that your app's Symfony version is 3.3+, 4.x, or 5.x (the new upper bound). Doctrine ORM 2.7 is the new floor for the dev/test matrix, but the ^2.7 constraint in 3.1.2 is a require-dev/suggest-level tightening — verify whether it's a runtime constraint in your copy of composer.json.
• First use case to validate the wiring: register the bundle, run bin/console debug:container and look for the service IDs it exposes, then exercise one read-only action (e.g. its controller/service) to confirm the DI graph resolves before you build feature work on top.

If you're on Laravel and hoping to use this in-app: stop and evaluate alternatives. Laravel does not ship framework-bundle, so the bundle's service provider, compiler passes, and config tree will not load. Anything you extract must be done at the component level (e.g. an individual class that only depends on symfony/validator or symfony/yaml), not by installing the bundle.

Implementation Patterns

Symfony-side integration (the intended path):

• Register the bundle in config/bundles.php (Symfony 4/5) or AppKernel::registerBundles() (3.x).
• Configure via config/packages/<bundle>.yaml, importing the bundle's default config and overriding keys. Use the config tree's nodes — Symfony will error on unknown keys, so this is also your discovery mechanism.
• Consume services via constructor injection; the bundle's compiler passes are what wire autoconfiguration, tags, and aliases. Don't reach into the container directly with $container->get().
• Twig integration means front-end templates come from @BundleName/...; override by shadowing under templates/bundles/<BundleName>/.
• Doctrine ORM 2.7 is the new baseline for the test suite — if you're on 2.6 you're outside the tested matrix going forward, even if ^2.4 still technically resolves in 3.1.x.

Cross-cutting with Laravel codebases:

• Isolate the few useful classes behind your own adapter/service. Anything that touches Symfony\Component\HttpKernel\Bundle\Bundle, ContainerBuilder, or FrameworkBundle event subscribers is not portable.
• For standalone pieces (YAML parsing, validation, expression language, finder), lean on Laravel's own equivalents (symfony/yaml is already shipped in Laravel's vendor tree via Symfony components) rather than pulling the bundle in.
• If you must share config between a Laravel and Symfony app, keep it out of the bundle's config tree — use plain arrays/env vars read by both.

Testing:

• 3.1.2 upgrades the test suite to PHPUnit 8.5. If you're writing integration tests downstream, align on PHPUnit 8.x and use setUp(): void signatures. PHPUnit 8.5 requires PHP 7.2+ (and 7.2.5+ if you also run Symfony 5).

Gotchas and Tips

• symfony/framework-bundle is a hard dependency. This is the single biggest gotcha for Laravel developers: the package cannot load outside a Symfony kernel. Treat any Laravel compatibility claim as "extract the component, not the bundle."
• Symfony 5 requires PHP 7.2.5+. The 3.1.2 constraint bump widens the range but doesn't lower the runtime floor. Confirm your CI image and production PHP version before upgrading.
• Doctrine ORM floor moved to ^2.7. Doctrine 2.7 changed several proxy/naming defaults and removed some deprecated APIs. If you were pinning to ^2.4 and haven't audited your entities/proxies, budget a pass before the upgrade.
• PHPUnit ^8.5 — return-type hints on setUp/tearDown and assertRegExp → assertMatchesRegularExpression renames will bite if you have custom tests touching the bundle. This does not affect runtime code.
• Autoloading and Flex. On Symfony Flex, composer require triggers a recipe; on older Symfony, you must edit AppKernel/bundles.php manually. Both paths are easy to miss — always verify with debug:container / debug:router.
• Config tree is strict. Unknown keys throw at container compile. When bumping minor versions, run bin/console lint:container and cache:clear immediately after upgrade — the config schema is the most common source of post-upgrade breakage.
• Twig bundle "*" constraint. The symfony/twig-bundle: * entry in the 3.1.2 notes means any version is accepted. This is loose — if you're debugging template resolution or block overrides, pin your Twig bundle to a known-good version in your app to isolate regressions.
• Debugging tips. Use bin/console debug:event-dispatcher, debug:container --tag=<tag>, and the Symfony profiler's "Doctrine" and "Twig" panels. If a service is missing, it's almost always a compiler pass not running because the bundle wasn't registered or was registered conditionally in Kernel::registerBundles().
• Extension points. The bundle's Extension class is what owns the config tree; its CompilerPassInterface implementations are where tag-based services are wired. If you need to override one of its services, prefer a compiler pass decorating the service (Symfony 3.3+ supports setDecoratedService / decoration) over editing vendor config.
• Laravel-adjacent caution. Laravel already ships Symfony components at versions driven by Laravel's own composer constraints. Adding this bundle to a Laravel app will force Symfony component versions that conflict with the framework — Composer will usually solve it by downgrading the bundle, silently reintroducing the Symfony 5 compatibility you upgraded for. Always composer why-not <vendor>/<package> after install to catch this.