Back2Front Laravel Laravel Package

Getting Started

This release (v2.10.0) is a compatibility/maintenance release, not a feature release. Nothing in it changes the package's public API — the only thing that moved is the framework and tooling floor. That shapes how you should approach it.

Before you touch anything:

1. Check what you're currently resolving. The single most useful command is:

   composer why-not vendor/package 2.10.0
   

   This tells you immediately whether the blocker is your Laravel version, your PHP version, or a pinned phpunit/phpunit constraint.
2. Confirm your floor. v2.10.0 requires Laravel ^11.0 and therefore PHP 8.2+. If you're still on Laravel 10, the upgrade path is closed and you should stay pinned to the last 2.9.x release.
3. Read the CHANGELOG and the package's own test suite. For a release with no functional changes, the tests are the best documentation of what "supported" actually means — check the CI matrix in the repo to see which Laravel/PHP combinations the maintainers actually run.
4. First use case: run composer update vendor/package --with-dependencies --dry-run -W in a branch, then run your own test suite against it. Because the diff is constraint-only, a green test run is genuinely sufficient confidence — you are not looking for behavioural regressions, you're validating that dependency resolution still lands where you expect.

Implementation Patterns

Constrain at the minor level, not the patch level. Use "vendor/package": "^2.10" so future Laravel 13.x support patches arrive without a manual bump. If you pin exact versions you will be doing this dance every release.

Mirror the maintainers' CI matrix, don't exceed it. A sensible matrix for this release:

matrix:
  php: ['8.2', '8.3', '8.4']
  laravel: ['11.*', '12.*', '13.*']
  exclude:
    - php: '8.2'
      laravel: '13.*'   # adjust per Laravel 13's actual PHP floor

Note the deliberate omission of 8.5 — see Gotchas.

Align your PHPUnit floor deliberately. The ^10.5.35 minimum is not arbitrary; it almost certainly reflects a bug fix the maintainers rely on for their own suite (data providers, annotations-to-attributes migration, or deprecation handling). If your app suite is still on PHPUnit 9, this release forces the migration: convert @dataProvider/@test docblock annotations to #[DataProvider]/#[Test] attributes and move setUp(): void return types. Budget for that separately from the package bump — it's the only part of this upgrade with real work in it.

Testbench versions travel with Laravel versions. If you maintain a package that depends on this one, keep orchestra/testbench in lockstep — mismatched testbench is the most common cause of "it works in CI but not locally" after a Laravel bump.

Use automation for the framework bumps themselves. Renovate/Dependabot rules keyed on illuminate/* and laravel/framework will surface these compatibility windows before they become urgent, rather than after a security advisory forces a scramble.

For local parity, the Docker image bump is optional but convenient — if you already use Sail or a project container, bumping the base image to PHP 8.5 lets you test ahead of your declared floor without shipping a higher floor.

Gotchas and Tips

• The PHP 8.5 change is a dev-container change, not a requirement. This is the most likely misreading of the release notes. The maintainers build and test in PHP 8.5; the package almost certainly still runs on 8.2. Do not add "php": "^8.5" to your own composer.json off the back of this — you'd lock out every consumer on 8.2/8.3/8.4 for no benefit. Check the package's own require block (not its Dockerfile) for the authoritative floor.
• A minor version bump can still be breaking for you. Dropping Laravel 10 in 2.10.0 under a ^2 constraint is legal semver but operationally breaking. Read the require stanza, never assume the version number tells the whole story. If you're on Laravel 10, pin "vendor/package": "2.9.*" explicitly and add a comment explaining why.
• Silent version backtracking. If your app pins phpunit/phpunit below 10.5.35, Composer won't error — it will quietly resolve an older version of this package. You'll think you upgraded and you didn't. Verify with composer show vendor/package after updating and confirm the version string.
• --with-dependencies matters here. Constraint-only releases interact with illuminate/* version widening elsewhere in your tree. composer update vendor/package alone can leave you in a split state where the package expects Laravel 13 interfaces but your framework is pinned to 12. Use -W (--with-all-dependencies) in the branch, then lock down the resulting diff carefully.
• Debugging resolution failures: composer show vendor/package --all lists available versions and their constraints without touching your lockfile; COMPOSER_MEMORY_LIMIT=-1 if the solver times out on large trees. For genuinely opaque conflicts, composer update --dry-run -vvv names the specific package pair that can't be satisfied.
• Extension points are unchanged, but that also means: if you were relying on an unofficial workaround to get the package running on Laravel 13 (a fork, a replace block, a patched constraint via repositories), remove it now. Leftover replace/alias hacks are the usual cause of "why is my lockfile still resolving the fork?"
• Verify the maintainers actually test Laravel 13. "Support added" in a release note sometimes means "the constraint was widened." Check whether the CI config in the repo includes a 13.x job — if not, treat 13.x as best-effort for now and keep an eye on the next patch release.
• Re-run the package's dependency audit on upgrade. composer audit after the bump is cheap and catches transitive dev-dependency drift from the "update dev dependencies" line, which is otherwise invisible in the notes.