Getting Started

Install with composer require strata/frontend. v0.10.0 adds Symfony 8 support, so confirm your symfony/* constraints resolve cleanly before adopting (composer why-not symfony/<component> "^8.0" is a fast check if resolution fails).
Look first at the package's service provider and any publishable config (php artisan vendor:publish --provider="Strata\Frontend\...") to understand how it hooks into the framework. The README's primary integration example is the fastest path to a working setup.
First use case: on a Symfony 8 / current-Laravel project, wire the package into a single view or frontend entrypoint and confirm the happy path renders before customizing. Because this release is a compatibility bump, the fastest validation is "does the existing quick-start still run unchanged on Symfony 8?"

Implementation Patterns

Pin by Symfony line. v0.10.0 targets Symfony 8. If you're still on Symfony 6/7 (or an older Laravel that constrains Symfony), stay on the prior 0.9.x tag rather than mixing versions — the two "Symfony 8 support" entries in the changelog are parallel dependency-matrix commits, not separate feature sets.
Treat this as an upgrade gate, not a feature. The release is a dependency-compatibility update, so the pattern is: bump strata/frontend to ^0.10, run composer update with your Symfony set already on 8, then smoke-test the frontend build and any Blade/view integration.
Keep the frontend pipeline Laravel-native. Layer the package over Laravel's asset/view tooling rather than replacing it; on Symfony 8 this generally means your symfony/* transitive deps and Laravel version must move together.
Lock in a test project. Before rolling the bump across production apps, verify in a minimal Laravel app pinned to Symfony 8 so a failed resolution doesn't block an unrelated deploy.

Pre-1.0 semver. At 0.10.x, minor bumps can carry breaking changes. Read the CHANGELOG diff between v0.9.0...v0.10.0 — here it's just Symfony 8 support, so the risk is low, but the 0.x contract still permits breakage.
Symfony 8 is the constraint lever. If install fails after upgrading the package, the culprit is almost always a transitive symfony/* package or an older Laravel that can't move to Symfony 8. Check composer why-not output rather than downgrading blindly.
Debugging resolution noise. Two identical "Symfony 8 support" bullets in the notes are a release-notes artifact (parallel commits); don't hunt for a second hidden feature.
Extension points to watch on upgrade. If you've overridden a published config or extended a provider, re-diff your published files after the bump — dependency-only releases occasionally ship regenerated defaults.
Rollback plan. Keep 0.9.x pinned in environments not yet on Symfony 8; there's no stated deprecation path here, so the safe move is to only adopt 0.10.0 once the Symfony 8 upgrade is already green.