Bundle Toolbox Laravel Package

Getting Started

Treat v1.2.5 as a dependency-signal release, not a behavioral one. The entire note is Symfony 6.X, which almost always means the package widened its symfony/* constraints (typically ^5.4 || ^6.0) and adjusted code for Symfony 6's PHP 8.1 baseline and native return types. Nothing in the note announces a feature or a breaking API change on the package's own surface — but pulling the package forward can drag Symfony 6 into your app, which is where the real work is.

Minimal steps:

1. Check your floor. Symfony 6.x requires PHP >= 8.1. Confirm php -v, php artisan --version, and that your Laravel version can carry it (Laravel 9.x → Symfony 6.0–6.2, Laravel 10 → 6.2/6.3, Laravel 11 → 6.4/7). Laravel 8 apps are stuck on Symfony 5.4 and cannot take this release.
2. Read the constraint before updating.

   composer show <vendor>/<package> --all | grep -i -E 'symfony|php|laravel'
   

   Look at require for php and each symfony/* entry. That is the actual changelog here.
3. Update on a branch, with transitive resolution:

   composer update "<vendor>/<package>" --with-all-dependencies -W
   

4. Confirm what you landed on:

   composer why-not symfony/http-foundation ^6.0
   composer show symfony/http-foundation symfony/http-kernel
   

First use case: in a Laravel 9/10 app, bump the package and exercise the code path where it actually touches Symfony — HTTP request/response handling, a console command, mailer transport, filesystem, or process execution. Boot the app (php artisan about), hit one route that uses the package, and run its command if it registers one. That single smoke pass is usually enough to expose return-type incompatibilities.

Implementation Patterns

Pin and lock deliberately. In composer.json, keep the package at a caret constraint and let the lock file record the Symfony major. When you need to stay on 5.4 for another dependency, add an explicit conflict rather than relying on resolution order:

"conflict": { "symfony/http-foundation": "<5.4" },
"require": { "symfony/http-foundation": "^5.4 || ^6.0" }

Feature-detect, don't version-sniff. If you maintain code around the package's Symfony touchpoints, branch on presence of a class or method, not on Kernel::VERSION:

if (class_exists(RequestEvent::class)) {
    // Symfony 5.4+/6.x path
}

This survives the next major cleanly.

Keep Symfony behind your own seam. Wrap the package's Symfony-facing service in a small interface bound in a service provider. When the next Symfony major lands, you change one adapter instead of grepping call sites:

$this->app->bind(Transport::class, fn ($app) => new PackageTransport($app->make(Client::class)));

Run a two-major CI matrix. Test against the lowest and highest Symfony you claim to support (^5.4 and ^6.0) plus your minimum PHP. Symfony's own symfony/phpunit-bridge surfaces deprecations as failures, which is the cheapest early-warning system you have.

Sequence deployment correctly. Bump the PHP version in your Docker image / CI runner before merging the composer change. A lock file generated on PHP 8.2 installed on a PHP 8.0 host fails at runtime, not at install.

Gotchas and Tips

• Return types are the trap, not the API. Symfony 6 added native return types across its interfaces. Any class of yours extending or implementing a Symfony type without a matching return type throws Declaration of ... must be compatible at autoload time — often in an unrelated request. If a page 500s immediately after the bump, this is the first suspect.
• Annotations are gone from the framework stack. Routing, validation, and serialization moved to PHP attributes. If the package or your integration code relied on doctrine/annotations being transitively present, add it explicitly or migrate to attributes.
• Removed legacy event classes. GetResponseEvent, FilterResponseEvent, and LegacyEventDispatcherProxy no longer exist. Anything still typing against them will fatal.
• Debug resolution with why-not, not guesswork.

  composer why-not symfony/console ^6.0
  composer depends symfony/http-foundation
  

  This names the package holding you at 5.4 far faster than reading the solver's prose.
• --with-all-dependencies vs --with-dependencies. Only the former will relax transitive constraints. Restricting the update to one package without it usually just fails with a confusing conflict.
• Never hand-edit composer.lock. If resolution is wedged, delete the lock in a throwaway branch and regenerate, then diff.
• Clear everything after the bump — php artisan config:clear route:clear view:clear, and restart php-fpm/Octane so opcache doesn't serve pre-bump class signatures.
• Watch deprecations in logs. Set LOG_DEPRECATIONS_CHANNEL to a dedicated channel during rollout; the pre-6.x deprecations you're still triggering tell you what breaks at the next major.
• The release note is too thin to trust alone. Diff the tag (composer diff, or the GitHub compare view between the previous tag and v1.2.5). A one-line note often hides constraint tweaks to php, illuminate/*, or a test-only CI change that affects your supported matrix.
• Extension points are unchanged. This release doesn't advertise new hooks — if you were relying on a service binding or config key, it still applies. Don't refactor around a compat bump.