Symfony Middleware Bundle Laravel Package

Getting Started

This release (1.1.0) adds support for Symfony 7.0 components. It is an additive compatibility change — no breaking API changes for existing consumers — but it does raise the effective PHP floor for anyone resolving against Symfony 7.

1. Install / upgrade

   composer require your-vendor/your-package:^1.1
   

   If you are already on ^1.0, a normal composer update will pull 1.1.0 provided your symfony/* constraints allow ^7.0.

2. Where to look first

   • composer.json of the package: inspect the symfony/* constraints. You will now see something like "symfony/console": "^6.4 || ^7.0" (or ^5.4 || ^6.4 || ^7.0). This is the contract that determines whether you can actually use the new support or merely install it.
   • The package's CHANGELOG.md / release page — the diff of composer.json is the meaningful part of this release.
   • config/ published config, unchanged in this release but the usual place to verify defaults after an upgrade.

3. First use case

   • If you are on Laravel 11 + PHP 8.3 and pulling in Symfony 7 components transitively, this version is what unblocks you: previously Composer would hold the tree back at Symfony 6.x. Run composer why symfony/console and composer update --with-all-dependencies to confirm the stack now resolves to 7.x.
   • If you are on Symfony 6.x or Laravel 10, you need do nothing — 1.1.0 resolves identically to 1.0.x for you.

Implementation Patterns

• Upgrade-and-verify workflow. Treat this as a dependency-hygiene release rather than a feature release. The correct pattern is:

  1. composer update your-vendor/your-package --with-all-dependencies
  2. composer show symfony/console symfony/process symfony/console — confirm major versions
  3. Run the app test suite (php artisan test) plus a container boot smoke test (php artisan about, php artisan config:cache then config:clear)
  4. Deploy to staging and exercise any artisan commands or process invocations that route through Symfony components.

• Feature-detect rather than assume. If your own code branches on Symfony behaviour, keep using class_exists() / method_exists() checks against the Symfony 7 API rather than version sniffing Kernel::VERSION. Code written against Symfony 6.4 interfaces generally works on 7.0, but this makes it explicit.

• Multi-version CI matrix. The right integration tip for a package advertising ^6.4 || ^7.0 is to test both. Add a job dimension on symfony/*:

  matrix:
    symfony: ['^6.4', '^7.0']
  steps:
    - run: composer require --no-update "symfony/console:${{ matrix.symfony }}"
    - run: composer update --prefer-dist --no-interaction
    - run: vendor/bin/phpunit
  

• Service container parity. Symfony 7 tightened a number of deprecations into errors around container compilation and autowiring. If this package registers bindings into the Laravel container that are passed to Symfony services, verify them with php artisan tinker → app()->make(YourService::class) before and after the upgrade.

• Console / Process integration. Symfony 7's Console and Process components changed default behaviours in edge cases (signal handling, verbosity mapping). If you use this package to spawn sub-processes or register commands, assert exit codes and output in tests rather than eyeballing terminal output.

Gotchas and Tips

• PHP floor. Symfony 7 requires PHP >= 8.2. If your app or CI still runs 8.1, Composer will silently resolve to Symfony 6.4 — you will not get an error, and you will not be exercising the new support. Check php -v in every environment (local, CI, production, queue workers, cron).

• composer.json is the real release note. The changelog line is one sentence; the constraint widening is the whole change. Diff the package's composer.json between 1.0.x and 1.1.0 before assuming anything about behaviour.

• Other packages pinning Symfony 6. A single transitive dependency with "symfony/console": "^6.0" will keep the whole tree on 6.x and make your 1.1.0 upgrade look like it "didn't work." Use composer why-not symfony/console 7.0 to find the blocker before filing a bug.

• composer.lock in libraries vs apps. In applications, commit the lock file so the Symfony major is reproducible. In a package you maintain, don't — but do test against both majors.

• Cached config and compiled containers. After the upgrade run php artisan optimize:clear (or config:clear, route:clear, view:clear) on every environment, including queue workers and Octane workers. php artisan octane:reload if applicable — a stale compiled container is the most common source of "it broke after upgrade" reports.

• Deprecations are now louder. Symfony 7 promotes several 6.4 deprecations to errors/deprecation notices. If you see Since symfony/... is deprecated in storage/logs/laravel.log after upgrading, fix at the call site; the package itself does not suppress these.

• Extension point to watch. If the package exposes a config flag or binding for the Symfony version/adapter, that is the seam to inspect when behaviour differs between 6.4 and 7.0 — it will be the first place to look and the safest place to override without forking.

• Rollback is cheap. Because 1.1.0 is additive, composer require your-vendor/your-package:1.0.* is a clean rollback if Symfony 7 surfaces an incompatibility in your app. Keep that in your deploy notes.