Laravel Octane Middleware Laravel Package

Getting Started

This release is a compatibility release, not a feature release. The headline is Laravel 13 support, which means the practical first step depends on which side of the upgrade you are on:

• Already on Laravel 13? v1.7 is the first version you can install without --ignore-platform-reqs or a Composer conflict. Bump the constraint (^1.7) and run your existing test suite — that is the whole migration for most apps.
• On Laravel 11/12 and not upgrading yet? Nothing forces you to move. Because the CI pipeline now tests a mixture of PHP and Laravel version combinations, the older combinations remain explicitly covered, so staying pinned is a supported position rather than an untested one.
• Starting fresh? Read the package's README for the service provider registration and publishable config first, then check composer.json for the PHP floor — the Laravel 13 branch of the matrix implies a newer PHP minimum than earlier releases, and that is the constraint most likely to bite you before anything in the package itself does.

The first real use case is unchanged: install, publish config if the package ships any, and wire the package into one existing flow (a job, a controller action, a console command) rather than building a greenfield feature around it. That gives you a smoke test against your actual Laravel version before you invest further.

Implementation Patterns

Treat the version constraint as the integration point. In composer.json, constrain to ^1.7 if you want Laravel 13 later without a second upgrade cycle. If you support multiple Laravel majors across your own packages or a monorepo, mirror the package's approach: widen the constraint (^1.6 || ^1.7) rather than forking.

Match your CI matrix to theirs. The most reusable thing in this release is the testing strategy. If the package is validated across a grid of PHP × Laravel versions, your application CI should assert at least the two cells you actually deploy: your current production combo, and the next one you intend to move to. This is how you discover a Laravel 13 incompatibility in a branch instead of during an upgrade.

Upgrade in a branch with the framework bump, not before it. Do the Laravel 13 upgrade and the v1.7 bump in the same PR. Splitting them creates an intermediate state that nobody tests and makes bisecting a failure ambiguous — you won't know whether the framework or the package caused it.

Pin in composer.lock and review the diff. A patch-level bump whose only change is constraint widening and CI config should produce a lockfile diff touching almost nothing else. If composer update pulls in transitive changes, that is your signal to look closer before merging.

Integration tip: if the package registers listeners, middleware, or scheduled work through a service provider, verify those registrations still resolve after the bump — php artisan about and php artisan event:list are cheap ways to confirm the provider booted and hooked in as expected.

Gotchas and Tips

• "Laravel 13 support" usually means a widened constraint, not rewritten internals. Don't assume behaviour changed. Equally, don't assume it didn't — read the diff of composer.json and the service provider before trusting a patch bump.
• PHP floor mismatch is the most common failure mode. Laravel 13 pulls a newer PHP minimum. If your local or CI image is behind, you'll see a Composer platform error that looks like a package problem but isn't. Check php -v against the package's require block first.
• Green CI on their matrix is not green on your app. Their combinations are generic. Your app's combination of database driver, queue backend, and third-party packages is not in that matrix. The matrix tells you the package is maintainable across versions, not that your integration is.
• Watch for --ignore-platform-reqs hiding in your setup. If you previously installed an older version with flags to bypass constraints, Composer's memory of that can mask a real incompatibility. Run composer why-not <vendor>/<package> 1.7 to see what is actually blocking you.
• Deprecation noise in Laravel 13. Framework majors frequently deprecate things the package may still call internally. Run your suite with deprecation notices surfaced rather than silenced, so you learn about them now rather than at the next major.
• Extension points are the fragile surface. If you subclass or override package classes, or bind your own implementation into its container keys, those are the places a constraint-only release can still break you. Re-read the changelog for the majors between your old version and 1.7 if you skipped any.
• Debugging tip: when the package misbehaves after the bump, isolate with a minimal reproduction outside your app skeleton. If it fails there, it's the package; if it passes, it's your integration — and you've avoided a long thread with the maintainers.