Laravel Favorite Laravel Package

Getting Started

v6.0.0 raises the floor to PHP 8.3 and adds Laravel 13 support, so the first step is a compatibility check rather than an install.

1. Verify your runtime before anything else. Run php -v and check composer.json for a pinned config.platform.php. If you (or your CI image, Dockerfile, or Forge/Cloud server) are still on PHP 8.1/8.2, the install will fail with a constraint error rather than a helpful message.
2. Check the Laravel version. v6 targets Laravel 13, but confirm the package's illuminate/* constraints in composer.json — most packages support a range (e.g. ^11.0|^12.0|^13.0) rather than only the newest.
3. Install and publish.

   composer require <vendor>/<package>:^6.0
   php artisan vendor:publish --provider="<Vendor>\<Package>\<PackageServiceProvider>"
   

4. Look first at: the package's config/<package>.php, its service provider's register()/boot() methods, and any published migrations. Those three places tell you what is bindable, what is configurable, and what persists.

First use case: wire the package into a single, low-risk code path (one controller or one queued job) and exercise it end-to-end in a test before touching production config. Because v6 is a major, treat the first integration as a smoke test of the upgrade, not just of the feature.

Implementation Patterns

Resolve from the container, don't instantiate. Bind the package's contract (or resolve the concrete class) via the container so test doubles and config overrides work. Facades are convenient in controllers; constructor injection is better in services and jobs.

Config over constants. Anything the package exposes in its published config should flow from config/*.php → env(). Hardcoding driver names, endpoints, or table names in application code is the most common source of pain when the package majors bump.

Queue and event integration. If the package dispatches events or ships jobs, register listeners in a dedicated EventServiceProvider-style location rather than inline in boot(). For queued work, set explicit $tries, $backoff, and a failed() handler — package-shipped jobs often assume defaults that don't match your queue driver.

Testing. Use the package's fake/swap mechanism (or $this->instance(Contract::class, $fake)) in feature tests, and keep one thin integration test that hits the real driver so a version bump surfaces breakage. Http::fake() / Queue::fake() around package calls keeps suites fast.

Upgrade workflow from v5 → v6. In order:

composer why-not <vendor>/<package> "^6.0"   # see what's blocking
composer update <vendor>/<package> --with-dependencies -W
php artisan vendor:publish --tag=<package>-config --force   # diff the new config

Diff the new config and migration stubs against your published copies — a major release will usually add keys, and silently missing keys surface as runtime nulls rather than errors.

Multi-environment rollout. Ship the PHP 8.3 bump and the package bump as separate deploys where possible. If they must land together, gate the package's feature behind a config flag so you can disable it without a rollback.

Gotchas and Tips

• PHP 8.3 is a hard floor, and it bites in four places: your CI matrix, your config.platform.php pin, your Docker base image, and your local Herd/Valet/Sail runtime. Update all four or you'll get green local / red CI.
• -W is usually required. composer update <package> alone often leaves transitive dependencies on v5-era constraints. Use --with-dependencies -W and read the diff.
• Laravel 13 support ≠ Laravel 13 only. Verify the actual constraint before assuming you can drop Laravel 11/12 from your support matrix.
• Lock files in monorepos. Each app needs its own composer update; a shared lock will happily keep half your services on v5.
• Stale caches mask upgrade problems. After bumping, run php artisan config:clear && php artisan cache:clear && composer dump-autoload. Config caching will happily serve the old shape of a config array that no longer matches the new code.
• Watch for silent deprecations. Major releases that "just add platform support" often still remove deprecated methods. Grep your codebase for the package's namespace and check each call site against the upgrade guide; deprecation notices may be logged rather than thrown.
• Extension points worth knowing: container bindings (swap implementations), published config (behaviour), package events (observability), and any Macroable traits or custom driver registries. Prefer these to subclassing internals — internals are exactly what majors change.
• Debugging tip: when something fails only in production, confirm the package isn't reading a cached config compiled under the old version. php artisan about plus php artisan config:show <package> is the fastest sanity check.