Laraflash Laravel Package

Getting Started

Check your runtime floor before anything else. 6.0.0 drops Laravel 9 and PHP 8.0, so the package now requires Laravel 10+ and PHP 8.1+ (8.2 explicitly supported). Verify with php -v and composer show laravel/framework, then bump composer.json if needed — installing on Laravel 9 will fail resolution, not fail at runtime, so the error surfaces early and is usually self-explanatory.

composer require <vendor>/<package>:^6.0
php artisan vendor:publish --provider="<Vendor>\<Package>\<Package>ServiceProvider"

Where to look first:

1. composer.json of the package — read the require block to confirm the exact Laravel/PHP constraints rather than trusting the notes alone.
2. config/<package>.php after publishing — this is where 90% of day-to-day behaviour is tuned.
3. The service provider — confirms auto-discovery, what bindings are registered, and whether a facade or helper is exposed.

First use case: get the package's default path working end-to-end on a single model/route/job in a scratch branch before touching production config. Since this release is compatibility-only (no new API surface, no deprecations beyond the support matrix), the "first use case" is unchanged from 5.x — if you already have usage in a Laravel 9 app, that exact code path is your migration smoke test.

Implementation Patterns

Upgrade as a coordinated bump. The 6.0.0 diff is purely a support-matrix change, so pair it with your own Laravel 9→10 and PHP 8.0→8.2 moves in one PR. Splitting them creates a window where you're debugging framework upgrade issues and package upgrade issues simultaneously.

Pin the major, float the minor. Use "^6.0" in composer.json. Because 6.0.0 introduces no behavioural changes, subsequent 6.x patches should be safe to absorb via composer update — there's no reason to pin an exact patch here.

Gate on the framework, not the package. In multi-app or package-of-packages setups, express the constraint once in the root composer.json (laravel/framework: ^10.0, php: ^8.1) and let the package constraint follow. Avoid --ignore-platform-reqs to force an install — with a support-matrix-only release you gain nothing and lose the guarantee that CI matches production.

Cover both supported PHP minors in CI. 8.1 is the new floor and 8.2 is newly supported; a matrix of php: [8.1, 8.2] × laravel: [10.x] is the cheapest way to catch the deprecation notices that typically appear when a package first declares 8.2 support.

Integration tip: if the package is behind an interface or bound in a service provider, the upgrade is often a no-op for your application code — you only touch composer.json and CI config. Grep your codebase for direct references to the package's concrete classes before assuming that.

Gotchas and Tips

• "Add PHP 8.2 support" is not the same as "8.2 was broken." It means 8.2 is now in the tested matrix. If you were already on 8.2 with 5.x, you may have been running untested-but-working code. Upgrade anyway to get the CI guarantee, but don't expect a fix for a specific bug.
• Transitive constraint conflicts are the most likely failure mode. Dropping Laravel 9 means any dev dependency still requiring ^9.0 will block resolution. Diagnose with composer why-not laravel/framework 10.* rather than deleting the lock file.
• Lock file staleness. After bumping, run composer update <vendor>/<package> --with-dependencies rather than a bare composer require, so Laravel's own sub-dependencies move together.
• Check your own published config and cached bootstrap. If you publish config or cache routes/config in deploy, clear them (php artisan config:clear && php artisan cache:clear) as part of the deploy step — stale cached providers referencing the old package version produce confusing "class not found" errors that look like an install failure.
• No new extension points in this release. If you were waiting on 6.0.0 for a new hook or driver, it isn't here — the extension surface is whatever 5.x exposed. Budget the upgrade as pure maintenance, not as an opportunity to refactor integration code.
• If you must stay on Laravel 9, pin ^5.0 explicitly. Version 6.0.0 will not install, and leaving the constraint loose (* or >=5) invites a confusing resolution failure in a later unrelated composer update.