Laravel Developer Laravel Package

Getting Started

• Confirm the version boundary first. 7.0.0 is a major bump whose only stated change is Laravel 13 support. Treat it as "the Laravel 13 line" of the package: before anything else, check composer.json for the php and illuminate/* constraints and make sure they match your app. If you are on Laravel 11/12, you may be able to stay on 6.x — pin deliberately rather than letting composer update decide.
• Install and smoke-test in one pass. Add the constraint, run composer update <vendor>/<package>, then immediately php artisan config:clear && php artisan cache:clear before booting the app. A stale cached config or compiled service manifest is the most common reason a package that "supports Laravel 13" still blows up on first request.
• Look at the package's own docs in this order: the composer.json requirements → the service provider's register()/boot() → config/<package>.php → the UPGRADE.md/CHANGELOG.md (a 7.0.0 with a one-line changelog almost always has a fuller upgrade guide separate from the release notes).
• Publish and diff, don't publish and forget. php artisan vendor:publish --tag=<package>-config (and -migrations if present) into a scratch branch, then diff against whatever you already have committed. New major versions frequently ship config keys that older published files silently lack.
• First use case: pick the single shallowest call path through the package — one read/one query/one render — and exercise it from php artisan tinker or a throwaway route on a local Laravel 13 app. Get that green before wiring it into jobs, listeners, or controllers. When a release only claims framework compatibility, that one call path is your entire verification surface.

Implementation Patterns

• Isolate the package behind your own boundary. Define a small interface or wrapper service (e.g. App\Support\<Domain>\<Package>Gateway) and bind the package's real implementation to it in a service provider. Day-to-day this means an upgrade like 6.x → 7.0.0 changes one binding, not forty call sites, and it gives you a seam to fake in tests.
• Prefer constructor injection over facades. Resolve the package's classes through the container so that if the major version renames or re-namespaces anything, the failure is a single "target not instantiable" at boot rather than a scattering of runtime errors in production paths.
• Stage the upgrade behind a branch, then a canary. Work in a branch with the Laravel 13 + package 7.0.0 bump as one atomic commit, run the full suite, deploy to staging, and only then roll forward. Do not mix this upgrade with feature work — the blast radius is framework-level.
• Keep a CI matrix that straddles the boundary. If you maintain anything downstream of this package (an internal package, a shared module, a second app), test against both the current and next Laravel major. A package adding Laravel 13 support is the signal that your own constraints need broadening, and CI is where you find out cheaply.
• Lock the version in composer.lock and review the diff on update. In a major-version world, ^7.0 is not a promise of API stability — it's a promise that 8.0.0 will be the next break. Review composer.lock changes to this package the same way you'd review application code.
• Re-run your cache-warming and queue-restart steps as part of the upgrade. php artisan optimize:clear, then re-warm. If the package registers commands, scheduled tasks, or queue hooks, verify they still register after the bump — providers that quietly fail to boot in a new major are a classic silent regression.
• Test with the package's fakes/spy hooks if it offers them; otherwise fake at your wrapper. Where the package ships a testing helper, use it. Where it doesn't, your own interface from the first bullet is the fake point, and the upgrade risk stays contained to integration tests.

Gotchas and Tips

• Release notes are not the changelog. "Added: support for Laravel 13" tells you nothing about what was removed to make that possible — dropped PHP versions, dropped facade aliases, renamed config keys, changed default values, removed deprecated methods. Read the full changelog and the commit range between the last 6.x tag and 7.0.0 before upgrading anything you care about.
• A major bump with only additive notes is a yellow flag, not a green one. Maintainers often reserve majors specifically to drop old framework support. Verify the minimum Laravel and PHP versions actually required by composer.json, and check whether the previous major is still receiving security patches.
• Config cache is the number-one upgrade footgun. After bumping, config:cache on a Laravel 13 app with a 6.x-era config/<package>.php will happily boot with missing or renamed keys and fail later, in a request, at 2am. Run php artisan config:clear locally and in every deploy target, and consider adding a boot-time assertion (abort_unless(config('<package>.key') !== null, ...)) if the package isn't strict about it.
• Published files drift silently. Published config, migrations, and views are yours now — the package will not update them. Any file you published on 6.x is frozen at 6.x semantics. Diff against the package's shipped stubs on every major upgrade; this is where most "it works in a fresh install but not in our app" bugs originate.
• Watch the facade/alias registration. Laravel's package auto-discovery caches (bootstrap/cache/packages.php) can go stale across a major upgrade. If the package seems "not installed," php artisan package:discover is your first debugging move, not your last.
• Deprecation noise is signal. Laravel 13 support means the package should be deprecation-clean on Laravel 13. Run your test suite with deprecations surfaced as failures (or at minimum grep the log) — it tells you which of your code paths the package now considers legacy, well ahead of 8.0.0.
• Extension points to check when something breaks: the package's service provider (what it binds and when), any Macroable/Factory/driver-manager registries it exposes (register your custom driver there rather than subclassing), and its event/listener hooks. Vendor patches are a last resort and cost you the next upgrade.
• Rollback plan: keep the previous composer.lock in the branch history so a bad deploy can be reverted to a known-good lock in one step. Database migrations shipped by the package are the one thing a composer rollback won't undo — read them before running.