Symfony Frontend Laravel Package

Getting Started

Orient first: this is not a Laravel package. strata/symfony-frontend targets the Symfony frontend stack (bundle + service wiring + asset tooling). In a Laravel codebase you will only meet it in three situations:

1. A hybrid monorepo where a Symfony app and a Laravel app live side by side and share a frontend build.
2. A Laravel app pulling in a Symfony bundle transitively through a third-party dependency.
3. A migration in progress (Symfony → Laravel or the reverse).

If none of those apply, stop here — there is nothing in this package that a pure Laravel app needs.

Minimal steps (Symfony side of the house):

composer require strata/symfony-frontend:^0.10.1

• Confirm the Symfony version constraint Composer resolved (composer show strata/symfony-frontend). v0.10.1 exists specifically to fix Symfony 8 support, so the constraint is the single most important thing to verify.
• Register the bundle in config/bundles.php if it is not auto-discovered.
• Look in config/packages/ for the extension alias and publish/adjust its config before writing any code.
• Run bin/console cache:clear and a frontend build once, before touching application code.

First use case: wire the package into a single existing Symfony frontend entry point (one asset/build config) and verify it renders end to end. Do not attempt a full frontend migration on the first pass — at 0.10.x the surface is still moving.

For Laravel developers specifically: read the package's composer.json (require + extra) before anything else. That tells you whether it drags in symfony/framework-bundle, symfony/asset-mapper, or similar, and whether it will conflict with your Laravel HTTP kernel. Nothing here registers a Laravel service provider, so expect manual wiring if you genuinely need it.

Implementation Patterns

Pin the constraint, don't float it. At 0.x, ^0.10 is the widest you should go. A frontend tooling package that has to chase Symfony major releases (see: Symfony 8 fixes landing in a patch release) will break on minor bumps.

"strata/symfony-frontend": "0.10.1"

Lock exactly in production; widen only when you have a green build against the new version.

Upgrade pattern for the Symfony 8 fix. If you were on 0.10.0 and running Symfony 8, upgrade in an isolated branch and validate the actual frontend output, not just that Composer resolves:

composer update strata/symfony-frontend --with-dependencies
bin/console cache:clear
# run your frontend build, then diff the emitted assets

Because the fix is compatibility-only, the risk is not API breakage — it is silent behavioural change in asset resolution/output. Diff the built artifacts.

Isolation pattern for hybrid repos. Keep the Symfony-side frontend build in its own directory with its own composer.json and lockfile. Do not merge it into the Laravel app's dependency graph. Cross-boundary sharing should happen at the build-artifact level (compiled assets on disk), never at the PHP dependency level.

Configuration as code. Put the bundle's config in config/packages/strata_frontend.yaml (check the extension alias) under version control, and keep environment-specific overrides in config/packages/{dev,prod}/. This is the pattern that survives 0.x churn best — when config keys move, you have one file to fix.

Integration tip for Laravel apps consuming the built output: publish the compiled assets into public/ via a build step, and treat that directory as generated. Do not let a Laravel-side Vite/Mix setup and this package both own the same output paths.

Gotchas and Tips

The 0.10.1 signal matters more than the fix. "Fixes to Symfony 8 support" shipped as a patch means Symfony 8 compatibility was claimed in 0.10.0 and was not fully working. Treat any Symfony-major compatibility claim from this package as unverified until you have built against it yourself. Test on the exact Symfony version you deploy.

Pre-1.0 means no deprecation contract. Minor releases can break config keys, service IDs, and directory conventions. Budget for reading the changelog on every composer update. Set "minimum-stability": "stable" and avoid --with-all-dependencies on this package unless you are deliberately upgrading.

Bleeding-edge Symfony is the risk surface. The package tracks Symfony majors reactively, not proactively. If you are on Symfony 8, expect a lag between a Symfony release and a working strata release, and pin Symfony itself so an unrelated composer update cannot strand you.

Debugging checklist when the frontend silently misbehaves:

• bin/console debug:container <service-id> — confirm the bundle's services actually registered.
• bin/console debug:config <alias> — confirm your YAML merged as expected (extension aliases and nesting are a common 0.x breakage point).
• bin/console cache:clear after every config change; Symfony caches compiled container config aggressively.
• Check var/log/dev.log for the bundle's channel before assuming it is a build-tool problem.

Composer constraint conflicts are the most likely failure mode in a Laravel repo. If composer require fails on symfony/* conflicts, do not --ignore-platform-reqs your way past it. That will surface later as runtime container errors. Either isolate the dependency or abandon it for that project.

Extension points to watch: bundle registration, the DI extension/config tree, and any Twig/asset helper namespace. These are the three places 0.x packages churn. If you need to customise behaviour, prefer decorating a service over forking the bundle — forks at this maturity level become unmergeable within one or two minor releases.

Laravel-specific caveat: there is no StrataFrontendServiceProvider, no facade, and no Laravel config publishing. Anything you read assuming a Laravel integration is an assumption you are importing from other packages. Verify against composer.json extra and the bundle class before writing integration code.