Symfony Behat Bundle Laravel Package

Getting Started

This release (v1.5.13) is a compatibility/maintenance release rather than a feature drop for application developers. The headline is that the package now declares support for Symfony 7.4 and 8.1 alongside the existing 5.4–7.x range, with a CI matrix covering PHP 8.3–8.5.

Minimal steps to adopt or upgrade:

1. Confirm your runtime is inside the new matrix. The tested floor is PHP 8.3. If you are still on PHP 8.1/8.2, do not assume this release works for you — check composer.json require constraints before running composer update. A patch-level release that quietly raises the tested floor is the single most common source of "works on my machine" breakage here.
2. Read composer.json first, then README.md. In a package whose selling point is framework-version breadth, the constraint block (php, symfony/*, illuminate/*) is the contract. If illuminate/support is not constrained, Laravel integration is happening purely through Symfony contracts — which is fine, but it changes how you register and configure it.
3. Check .github/workflows/ before trusting the green badge. CI moved from CircleCI to GitHub Actions in this release. Branch protection rules, required status checks, and any badge in the README pointing at CircleCI are now stale. If you consume the package via a private fork or a Satis/Composer repository mirror, re-point any CircleCI-based automation.
4. First use case: run the package's own test suite against your application's PHP/Symfony versions before wiring it in. Because the matrix is broad but not exhaustive per-Laravel-version, the combination you actually run (e.g. Laravel 11 + Symfony 7.4) is the one that needs verifying.

composer require <vendor>/<package>:^1.5 --with-all-dependencies
composer show <vendor>/<package>   # confirm resolved symfony/* versions
vendor/bin/phpunit --filter <Package>   # if you vendor integration tests

Where to look first in the source: the service provider / extension class (auto-discovery means it registers silently), the config file if one is publishable, and the tests/ directory — with a widened matrix, the tests are the best documentation of which Symfony version-specific code paths are actually exercised.

Implementation Patterns

Pin the package, let Composer solve the rest. With Symfony 5.4 through 8.1 supported, use a caret constraint on the package and let composer update --with-all-dependencies negotiate the Symfony version, rather than pinning symfony/* yourself. Manually pinning is how you end up on a supported package version but an unsupported transitive combination.

Treat Symfony-version branching as an application concern, not a package concern. If your app also depends on a Symfony component directly (HttpClient, Console, Serializer), your resolved Symfony version is now determined by whichever constraint is tightest. Verify with:

composer why symfony/http-foundation
composer outdated "symfony/*"

Laravel wiring. For a Laravel app, register through the container rather than instantiating directly — this keeps you compatible if the package later swaps its internal Symfony dependency:

// config/app.php providers (if not auto-discovered)
App\Providers\PackageServiceProvider::class

// resolve from container in a job/command
public function __construct(private PackageClient $client) {}

If a config file is publishable, publish it in deploy (php artisan vendor:publish --tag=<package>-config) rather than editing vendor files, so the CI-matrix upgrade does not wipe your settings.

CI parity. Mirror the package's new matrix in your own pipeline for the versions you actually ship on. You do not need all of PHP 8.3–8.5, but test your application's PHP version plus one ahead — that is where deprecation noise from Symfony 7.4/8.1 will surface first.

# .github/workflows/ci.yml
strategy:
  matrix:
    php: ['8.3', '8.4']
    symfony: ['7.3.*', '7.4.*']

Upgrade workflow for this specific release. Because 1.5.13 changes dependency metadata and CI but not the public API, the safe sequence is: bump in a branch → run full test suite → run static analysis (PHPStan/Psalm will catch Symfony signature changes the test suite misses) → deploy. Do not batch this with a Laravel major upgrade; you want a clean bisect point.

Gotchas and Tips

• A patch bump that widens framework support is not automatically low-risk. Widening symfony/* constraints means Composer may now resolve to Symfony 8.1 where it previously resolved 7.x. Your lockfile can move significantly on composer update. Review composer.lock diffs, not just the package changelog.
• Dropped test coverage is silent deprecation. The new matrix starts at PHP 8.3. If 8.1/8.2 are still in require but no longer tested, treat them as unsupported in practice and plan the upgrade — do not wait for an explicit removal notice.
• Symfony 8.x removal of deprecated APIs. If your app calls anything from the package that passes through a Symfony component, run with SYMFONY_DEPRECATIONS_HELPER=weak locally and inspect the deprecation log before enabling the wider constraint in production.
• CI migration fallout is external to the code. Update README badges, any Dependabot/Renovate config referencing CircleCI, and required status check names in GitHub branch protection. A stale required check will block every PR with "Expected — waiting for status".
• Debugging resolution problems: composer why-not symfony/http-kernel 8.1.0 is the fastest way to find which dependency is holding you back. Conflict messages here are usually about a transitive psr/* or symfony/polyfill-* constraint, not the package itself.
• Extension points: if the package exposes a Symfony bundle extension or a Laravel service provider binding, prefer decorating/overriding via container binding over forking. Forking means you own the matrix forever, which is precisely the maintenance this release just absorbed for you.
• Watch the next release. With 8.1 support landing in a 1.5.x patch, the maintainers are signalling a compatibility-first cadence. Expect further constraint widening in patches; pin with ~1.5.13 if you need resolution stability across deploys, and loosen later.