Symfony Template Bundle Laravel Package

Getting Started

This is a Symfony bundle published by TYPO3 GmbH, not a Laravel package — there is no service provider, no facade, no config/*.php publish tag, and Composer auto-discovery will not register anything for you. Treat it as a Symfony/TYPO3 integration dependency that you pull into a Symfony-kernel-based application (typically a TYPO3 v12/v13 install or a standalone Symfony app that shares TYPO3's templating conventions). If your day-to-day is pure Laravel, the realistic first use case is a TYPO3 site or a Symfony microservice in the same estate, not composer require inside a Laravel app.

Minimal steps:

1. composer require t3g/symfony-template-bundle inside the Symfony/TYPO3 project that will consume it.
2. Read the bundle source before the README — with ~5 stars and 0 dependents, docs will be thin. Start at composer.json (for Symfony/TYPO3 version constraints), then the bundle class (*Bundle.php), then DependencyInjection/*Extension.php and Resources/config/ to see what services and parameters are actually registered.
3. Register the bundle the Symfony way: add it to config/bundles.php (T3G\...\SymfonyTemplateBundle::class => ['all' => true]), or, in a TYPO3 context, enable the package in config/system/settings.php / package states.
4. Check config/packages/*.yaml for the bundle's config root (usually the lower-snake-case vendor/package name) and set template paths there.
5. First use case: inject the bundle's renderer/template service into a controller and return a Symfony\Component\HttpFoundation\Response built from a rendered template; confirm with bin/console debug:container | grep -i template that the service exists before writing code against it.

Implementation Patterns

• Service-first usage. Everything in a Symfony bundle is a container service. Autowire the renderer/template-locator interfaces the bundle exposes rather than instantiating classes; if an interface isn't obvious, run bin/console debug:container --show-private and search for the bundle's namespace.
• Controller rendering pattern. Keep controllers thin: resolve a template name, pass a view-model array, return the rendered string inside a Response. This mirrors Laravel's view() flow but with explicit Response construction.
• Configuration over convention. Template directories are configured, not auto-guessed. Define them per environment (config/packages/dev/...yaml vs prod) so you can point dev at a working directory and prod at a built/cached path.
• TYPO3 integration. When used inside TYPO3, wire the bundle into an extension's Configuration/Services.yaml and let TYPO3's Symfony DI container autowire it. Keep TYPO3's Fluid templates and this bundle's templates in separate directories to avoid resolution ambiguity.
• Bridging to Laravel. If a Laravel app must consume output, don't try to load the bundle — expose it behind an HTTP endpoint in the Symfony app and call it with Http:: from Laravel. Trying to shoehorn Symfony bundle bootstrapping into Laravel's container is more work than an HTTP boundary.
• Testing. Use Symfony\Bundle\FrameworkBundle\Test\KernelTestCase (or WebTestCase) and boot a minimal test kernel with the bundle registered; assert on rendered output rather than on internal service calls.
• Extension points. Prefer Twig extensions, event subscribers, and decorator services (decorates:) over forking the bundle; with this adoption level, upstream fixes are unlikely to arrive quickly, so keep your customizations in your own package.

Gotchas and Tips

• No Laravel auto-discovery. composer require alone does nothing in Laravel. There is no extra.laravel block to rely on; assume manual wiring or an HTTP boundary.
• Version pinning is essential. Last release is dated 2026-08-03 with 0 dependents and 5 stars — the compatibility matrix against Symfony minor versions is effectively untested by the community. Pin the bundle and the Symfony/TYPO3 versions together, and read the composer.json constraints before upgrading either side.
• Bundle registration differs by host. Symfony uses config/bundles.php; TYPO3 uses package states. Registering in the wrong place yields a "service not found" rather than a helpful error.
• Cache is the usual culprit. After changing bundle config or template paths, run bin/console cache:clear (Symfony) or flush TYPO3 caches. Stale compiled containers are the most common cause of "my config change did nothing."
• Debugging toolkit. bin/console debug:container <service>, debug:config <alias>, lint:twig, and lint:yaml will tell you more than the README. Use --env=dev and check var/log/dev.log for container compilation warnings.
• Template resolution order. If multiple paths are configured, the first match wins — namespace your templates (e.g., @Bundle/...) to make collisions obvious instead of silently rendering the wrong file.
• Config key naming. Symfony config roots are derived from the bundle name; if the documented key doesn't validate, run debug:config against the guessed alias to get the real one from the error message.
• Limited upstream support. With near-zero adoption, file issues with a minimal reproduction and be prepared to patch via a Composer repositories VCS entry or a local path repository; keep the patch isolated so it's easy to drop when upstream catches up.
• Don't assume Twig. "Template bundle" may wrap more than one engine or the Symfony Templating component; confirm which renderer is registered before investing in Twig-specific extensions.