Php Capsule Listener Laravel Package

Getting Started

This assessment is based on the 7.0.0 release note only — no prior evaluation exists, so treat the specifics below as the baseline to verify against the package's README and source.

1. Confirm your host app is on Laravel 9. The 7.x line supports Laravel 9 only. Run php artisan --version and check composer.json for laravel/framework: ^9.0 before you touch the package.
2. Require the new major explicitly. composer require vendor/package:^7.0. Do not rely on an unpinned constraint — a ^6 lock will silently keep you on the old line.
3. Look here first: composer.json (the require / require-dev blocks tell you the real Laravel and PHP floors), then the package's service provider (auto-discovered or manually registered) for what it binds, and finally any config/ file it publishes.
4. First use case: install into a fresh Laravel 9 skeleton, publish config/ migrations if offered, and exercise the package's headline feature end-to-end before integrating into your real app. This isolates "does 7.0.0 work on L9" from "does my app work on 7.0.0".

Implementation Patterns

Upgrade ordering. Upgrade Laravel to 9 first, get the app green, then bump the package to ^7.0. Reversing the order leaves you debugging two moving targets at once.

Pin and lockstep the constraint. In composer.json use "vendor/package": "^7.0" and commit composer.lock. For libraries that depend on this package, widen to ^7.0 only — do not carry ^6|^7 forward unless you genuinely test both.

CI matrix. If you maintain a package or a multi-app monorepo, make the matrix assert the new floor: Laravel 9 on the highest PHP it supports, plus the lowest PHP the package's composer.json permits. A single-job CI will not catch a stray Laravel 8 dependency creeping back in.

Resolution debugging. When composer update refuses to install 7.x, the cause is almost always a transitive dependency still capped at Laravel 8. Run composer why-not laravel/framework 9.0 and composer why-not vendor/package 7.0.0 to see the exact package and constraint blocking you, then upgrade or replace that dependency rather than forcing --ignore-platform-reqs.

Staged rollout. Because 7.0.0 drops older framework support, treat it as a breaking upgrade in your release process: branch, upgrade, run the full test suite plus any integration tests that touch the package's surface, and deploy behind your normal canary/feature-flag path.

Local verification of the integration seam. Whatever the package exposes — facade, helper, container binding, or events — write one thin adapter or wrapper in your app around it. That single seam is what you'll have to change at the next major, and it keeps the blast radius small today.

Gotchas and Tips

• "Support Laravel 9 only" cuts both ways. It is a floor and a ceiling. You cannot run 7.0.0 on Laravel 8, and there is no stated support for Laravel 10/11 — plan for another major bump when you next move frameworks. Budget for this rather than discovering it during an upgrade crunch.
• No compatibility shims implied. A major version that narrows framework support typically removes version-conditional code paths. If your app relied on behaviour that only existed under Laravel 8, expect it gone. Diff the changelog against your own usage before assuming parity with 6.x.
• PHP floor moves with it. Laravel 9 requires PHP 8.0+, so a Laravel 8 → 9 upgrade usually means a PHP bump too. Check your deploy images and any platform config in composer.json (e.g. "platform": {"php": "7.4"}) — a stale platform override is a classic cause of "why won't it resolve".
• Auto-discovery caching. After upgrading, run php artisan package:discover and php artisan config:clear. Stale bootstrap/cache/packages.php from the 6.x install will keep the old provider registered and produce confusing class-not-found or duplicate-binding errors.
• Transitive constraints are the real upgrade cost. The package itself is one line in composer.json; the effort is in the dependency graph around it. Do a composer update --dry-run early to size the job before committing to the sprint.
• Debugging checklist for a failed boot: composer diagnose → composer why-not for both the framework and the package → confirm the provider is registered exactly once → confirm published config/migrations match 7.x (re-publish rather than hand-merging if the package offers vendor:publish --force).
• Extension points are unverified. No source was available for this review, so confirm for yourself where the package allows customisation — container bindings, published config, contract interfaces, or events. Those are the places a future major will break you, so note them now while you're reading the code for the upgrade.
• Re-assess after first contact. This write-up rests on a one-line release note. Once you've installed 7.0.0, revisit the Implementation Patterns section with the real API surface in hand — the upgrade mechanics above will hold, but the usage patterns will need filling in.