Laravel Review Rating Laravel Package

Getting Started

The v3.2.0 release is a platform-support update: Laravel 12 is now supported, and Laravel 10 support has been removed. Before doing anything else, confirm which side of that line your application is on.

1. Check your Laravel version:

   php artisan --version
   composer show laravel/framework
   

2. Check the package's constraints before upgrading:

   composer show vendor/package --all
   

   You should see a laravel/framework requirement roughly like ^11.0|^12.0. If you are still on Laravel 10, v3.2.0 will not install.

3. Upgrade in the right order:

   • Laravel 10 app → upgrade Laravel to 11 first, or stay on the package's previous minor (^3.1) until the framework upgrade is done.
   • Laravel 11 app → v3.2.0 is a normal minor upgrade.
   • Laravel 12 app → v3.2.0 is the first version you should target.

4. First use case: after upgrading, run the package's existing test suite and one representative application flow (the feature that first caused you to install the package). This release is about compatibility, not new APIs, so the fastest signal is whether your current integration still behaves identically on the new Laravel major.

Where to look first:

• composer.json of both your app and the package for platform constraints.
• The package's CHANGELOG / upgrade notes for any Laravel 12-specific adjustments.
• Your CI matrix, which likely still lists Laravel 10.

Implementation Patterns

Pin by framework major in CI. Since this release changes platform support, make your test matrix explicit rather than relying on composer update to resolve the newest compatible set:

# .github/workflows/tests.yml
matrix:
  laravel: ['11.*', '12.*']
  include:
    - laravel: '11.*'
      testbench: '9.*'
    - laravel: '12.*'
      testbench: '10.*'

Use orchestra/testbench versions aligned with the Laravel major when testing the package or a package-like integration.

Constrain the package version deliberately. If you need to support both Laravel 10 and 12 deployments (for example, during a staged rollout), require a range that excludes the breaking minor:

{
  "require": {
    "vendor/package": "^3.1 || ^3.2"
  }
}

Then let Composer resolve per environment. In practice, Composer will select 3.1.x on Laravel 10 and 3.2.x on Laravel 11/12.

Use composer why-not to diagnose blocked upgrades. This is the fastest way to see whether the package or one of its transitive dependencies is holding you back:

composer why-not vendor/package 3.2.0
composer why-not laravel/framework 12.0

Upgrade workflow for an existing Laravel 11 app:

composer require vendor/package:^3.2 --with-all-dependencies
php artisan vendor:publish --tag=package-config   # only if config changed
php artisan optimize:clear
php artisan test

For new Laravel 12 projects, install the package during initial scaffolding so you do not carry forward a Laravel 10-era lockfile. Verify service provider auto-discovery and any published config/migrations immediately, because Laravel 12's skeleton and default configuration differ from what older docs may assume.

For package authors or internal forks, update your own composer.json and CI together:

{
  "require": {
    "php": "^8.2",
    "illuminate/support": "^11.0|^12.0"
  }
}

Dropping Laravel 10 generally means you can also drop PHP 8.1 support, since Laravel 11 and 12 both require PHP 8.2+.

Gotchas and Tips

• A dropped framework major in a minor release is a breaking change in practice. SemVer would normally call this 4.0.0. Treat v3.2.0 as breaking if you are on Laravel 10, and pin ^3.1 until your framework upgrade is complete. Do not let an unattended composer update pull it in.

• composer update may silently keep you on an older version. If your lockfile is already resolved to 3.1.x and your platform is Laravel 11, Composer may not move you to 3.2.0 without --with-all-dependencies. Check with composer outdated vendor/package.

• PHP version is the hidden constraint. Dropping Laravel 10 usually coincides with requiring PHP 8.2+. If your production images or CI runners are still on PHP 8.1, the package upgrade will fail at the platform check before any code runs. Verify with php -v in every environment, including queue workers and deployment containers.

• Upgrade Laravel first, package second. Trying to jump both the framework and the package in one commit makes failures hard to attribute. Do Laravel 10 → 11, run the suite, then move the package to ^3.2.

• Watch for transitive dependency conflicts. Other packages in your app may still cap laravel/framework at ^10.0. Use composer why-not laravel/framework 12.0 and resolve those before expecting this package's Laravel 12 support to help.

• Re-run queue workers and scheduled tasks after upgrading. Long-running workers hold the old package code in memory. Restart them explicitly:

  php artisan queue:restart
  

• Check service provider and config changes for Laravel 12. If the package publishes config, migrations, or registers bindings, confirm the published artifacts are current. Stale published config from a Laravel 10 install can mask new defaults.

• Deprecation noise is a signal, not just noise. Laravel 12 surfaces deprecations from packages that have not fully modernized. Run your test suite with deprecations visible and report anything originating inside the package rather than your app.

• Extension points are usually unchanged in a compatibility release. Do not expect new APIs in v3.2.0. If you maintain custom integrations, macros, or subclassed package classes, verify they still resolve after the upgrade rather than assuming the compatibility release is behavior-neutral.

• Rollback plan: keep the previous composer.lock and a tagged release. If v3.2.0 misbehaves on Laravel 12, composer require vendor/package:3.1.* should restore the prior state, assuming your framework version still satisfies its constraints.