Eh Symfony Laravel Package

Getting Started

• What changed in v1.1.0: the only shipped change is Symfony 7 compatibility. There are no new APIs, deprecations, or migration steps noted in the changelog, so this is a constraint-widening release rather than a behavioural one. For Laravel developers the practical meaning is that the package can now be installed alongside the Symfony 7 component line used by Laravel 11+; Laravel 10 and earlier (Symfony 6.4) should stay on ^1.0.4 unless the rest of the app has been upgraded.
• Confirm your Symfony line first: run php artisan about and composer show symfony/http-foundation (or symfony/console). Laravel 11 resolves Symfony 7 components; Laravel 10 resolves Symfony 6.4. This determines whether ^1.1 is even installable in your app.
• Install and inspect: composer require zoltanlaca/eh-symfony:^1.1, then read the package's composer.json (PHP and symfony/* constraints), README, and the diff between v1.0.4...v1.1.0. The diff is the fastest way to confirm the release really is constraint-only.
• Where to look first: the package's service provider/bundle class and any publishable config file. Those tell you how it expects to be registered and configured before you wire anything into a real application.
• First use case: add it to a throwaway Laravel 11 app, publish config if available, and exercise the package's primary entry point from a feature test. Validate on a fresh skeleton before introducing it to an existing codebase, because a Symfony 7 compatibility bump can surface transitive conflicts that only appear on install.

Implementation Patterns

• Pin per Laravel line. Treat the package version as coupled to your framework version: Laravel 11 / Symfony 7 → ^1.1; Laravel 10 / Symfony 6.4 → ^1.0.4. Put this in CI as a matrix rather than relying on Composer's resolver to pick correctly.
• Use an adapter layer. Because the package is Symfony-oriented, wrap its public classes behind a small application-level interface or service. That isolates your domain code from Symfony-version differences and makes the next compatibility bump a one-file change.
• Register explicitly if needed. If the package is bundle-shaped, don't assume Laravel will auto-register a Symfony bundle. Bind its services in an app service provider, or consume the classes directly via the container. Prefer constructor injection over facades so the adapter remains testable.
• Publish and own configuration. Use php artisan vendor:publish for any config file, commit the published copy, and treat it as application configuration rather than vendor state.
• Test with Orchestra Testbench. For package-integration behaviour, a small Testbench test case gives you a Laravel container without booting the full app, and it lets you run the same suite against both Symfony 6.4 and 7 constraints.
• Upgrade deliberately. composer update zoltanlaca/eh-symfony --with-dependencies on a branch, run the full suite, and check composer why-not before merging. A minor-version compatibility release is low risk but not zero risk.

Gotchas and Tips

• PHP floor: Symfony 7 requires PHP 8.2+. On PHP 8.1 Composer will quietly resolve back to 1.0.x; pin the version explicitly if you need 1.1 behaviour, otherwise you can believe you upgraded when you did not.
• Silent downgrades and conflicts: other packages capping symfony/* at ^6 will block 1.1. Diagnose with composer why-not symfony/console 7 and composer why zoltanlaca/eh-symfony rather than guessing from the lock file.
• Don't fight Laravel's own constraints. Laravel pins its Symfony components; overriding platform or aliasing Symfony packages to force 1.1 is fragile. Upgrade the framework line instead.
• Config cache: after publishing or editing package config, run php artisan config:clear. Stale cached config is the most common cause of "the package ignores my settings".
• Debugging checklist: composer show zoltanlaca/eh-symfony, php artisan about, the package's own test suite, and Laravel's log with debug enabled. If behaviour differs between environments, compare resolved Symfony versions first.
• Extension points: decorate or bind the package's interfaces in the container rather than editing vendor code; listen for any events it dispatches if it integrates with the framework lifecycle. Keep customisations in your adapter so future upgrades remain a version bump.
• No migration required from 1.0.x beyond the Composer update, but re-run your integration tests: a compatibility release can still change which transitive Symfony version your app resolves, and that is where regressions usually hide.