Laravel Request Accept Json Middleware Laravel Package

Getting Started

This release is a hard platform bump: laravel/framework ^12.0 and php ^8.5. Before anything else, confirm your application actually satisfies both — 5.0.0 will not install, and will not run, on Laravel 11 or PHP 8.4 and below.

1. Check your stack first. Run php -v and composer show laravel/framework. If either falls short, do not attempt the upgrade; pin to the latest 4.x line instead (composer require <vendor>/<package>:"^4.0").
2. Read the upgrade guide before the changelog. A major release paired with a Laravel major usually carries signature changes, renamed config keys, and dropped deprecated APIs beyond just the version constraints. Look for an UPGRADING.md or the release diff on the repo.
3. Install in a scratch branch. composer require <vendor>/<package>:"^5.0" --with-all-dependencies — the --with-all-dependencies flag matters because the Laravel 12 constraint will cascade through your lock file.
4. First use case: publish any package config/migrations (php artisan vendor:publish --provider="<Vendor>\\<Package>\\<Package>ServiceProvider") and get one existing 4.x call site working end-to-end before touching the rest. That single path surfaces most breaking changes cheaply.

If you're on an older stack, the correct action is no action — stay on 4.x. There is no compatibility shim in this release.

Implementation Patterns

Pin the platform, not just the package. Because 5.0.0 hard-requires PHP 8.5, add an explicit platform block to composer.json in CI and local dev so nobody silently resolves a different dependency tree than production:

"config": {
    "platform": { "php": "8.5.0" }
}

Stage the upgrade behind a branch and a matrix. Run your test suite against a CI matrix of Laravel 12 / PHP 8.5 only for the 5.x branch, and keep a 4.x maintenance branch on the old matrix until all consumers have migrated. If this package is a dependency of your own package, widen your constraint carefully — "^4.0|^5.0" only if your code genuinely works against both APIs.

Isolate the package behind a thin adapter. If you call this package from many places, wrap the calls you actually use in a small application-level service or facade of your own before upgrading. The migration then becomes a one-file change instead of a grep-and-replace across the codebase, and the next major (6.0) is cheap.

Keep the old lock file as a rollback artifact. Commit composer.lock on the upgrade branch as a separate commit from any code changes, so git revert restores a known-good dependency set without untangling hand-edited code.

Feature-flag the switch in production. Deploy the upgraded code with the new call path disabled, verify boot and container bindings resolve, then enable. Laravel 12's bootstrap and service-provider lifecycle is where version bumps most often bite, and it bites at boot rather than at request time.

Gotchas and Tips

• The version constraint is the breaking change. For many packages a major like this is only a platform bump — no API changes at all. Read the diff rather than assuming a rewrite; conversely, don't assume it's free either. Check whether 4.x deprecated anything that 5.0 removed.
• composer update will lie to you. If your local PHP is 8.4 but CI is 8.5, Composer resolves different trees locally. Always set config.platform.php (see above) or run the update inside the same container image CI uses.
• Watch transitive constraints, not just direct ones. A dev dependency (PHPUnit, Pest, Larastan, a queue or auth driver) may not yet declare Laravel 12 or PHP 8.5 support, which blocks the whole resolution. composer why-not laravel/framework ^12.0 is the fastest way to find the culprit.
• PHP 8.5 deprecations surface as noise, not errors. Run your suite with error_reporting(E_ALL) and treat deprecation notices as migration work — they become removals in PHP 8.6/9.
• Static analysis is your cheapest upgrade test. If the package ships or you maintain stubs/PHPDoc types, run Larastan or Psalm at your highest existing level on the upgrade branch; signature changes in the package will show up there before they show up in tests.
• Config and cache are stale-prone. After upgrading, run php artisan config:clear && php artisan cache:clear && composer dump-autoload. A cached service-provider manifest from 4.x is a classic source of "works locally, fails deployed" after a major bump.
• Don't backport. Resist copying 5.x code into a 4.x app to pick up a fix; the platform requirements mean 5.x code may use PHP 8.5 syntax or Laravel 12 APIs that simply won't parse or resolve. Request a 4.x patch release instead, or bring the upgrade forward.
• Extension points to re-check: anything you subclass — service providers, facades, custom drivers, published config files, and event/listener registrations — is where breaking changes hide even in "requirements-only" majors. Diff your published config against the new package default after upgrading.