Fixtures Laravel Package

Getting Started

This release (v9.0) is a compatibility bump that adds Laravel 9 support; it does not introduce new API surface on its own. Start here:

1. Confirm your runtime meets Laravel 9's baseline (PHP 8.0+) before pulling this in:

   php -v
   composer show laravel/framework | grep versions
   

2. Require the new major explicitly so you don't silently resolve an older line:

   composer require vendor/package:^9.0
   

3. Check the package's composer.json constraints (illuminate/support, php) — v9.0 is the first line that will resolve against laravel/framework:^9.0.
4. If the package ships a service provider, verify auto-discovery picked it up:

   php artisan about
   

5. First use case: wire the package's primary entry point into a single artisan command or controller action and exercise it once before integrating broadly — this validates the provider, config, and any facade bindings on Laravel 9 in isolation.

Where to look first: the package README, UPGRADE.md/CHANGELOG.md (for anything that changed between the last Laravel-8-compatible major and v9.0), and config/ if a publishable config exists.

Implementation Patterns

• Pin the major, not the patch. Use "vendor/package": "^9.0" in composer.json so the Laravel 9 compatibility line is explicit and reviewable in diffs.
• Resolve through the container. Bind any package interfaces in a dedicated service provider (App\Providers\PackageServiceProvider) rather than calling concrete classes directly; this keeps test doubles clean and isolates future major upgrades to one file.
• Config-driven setup. Publish config (php artisan vendor:publish --provider="Vendor\Package\ServiceProvider") and drive package behavior from config/package.php / .env rather than inline arguments — this is what makes the same code work across local, CI, and production on Laravel 9.
• Facade-first at call sites. If the package exposes a facade, use it in controllers/commands and keep the underlying class out of your application code. This is the cheapest hedge against internal changes in a future major.
• Queue long-running work. If the package performs IO or network calls, wrap usage in a job and dispatch it; this keeps request latency independent of package performance and plays well with Laravel 9's queue improvements.
• Test with fakes/mocks. In feature tests, bind a fake implementation of the package contract; in unit tests, assert on the facade with Facade::shouldReceive(...). Add one integration test that hits the real package to catch provider/config regressions on upgrade.
• CI matrix. Add laravel/framework:^9.0 and PHP 8.0/8.1 to your matrix so the compatibility this release adds is actually verified on every PR, not just locally.

Gotchas and Tips

• PHP 8.0 is a hard floor. Laravel 9 requires PHP 8.0+; if your CI or deploy image is still on 7.4, the composer require will fail or resolve an older package major. Check the deploy image, not just your laptop.
• Don't assume v9.0 is a drop-in from the previous major. "Support for Laravel 9" often ships alongside a major-version bump that drops Laravel 8 — read the UPGRADE.md before bumping. If the package still supports Laravel 8, the bump may be safe; if not, this is a coordinated upgrade with your framework version.
• Composer constraint conflicts are the most common failure. If composer require complains about illuminate/* or symfony/*, inspect with:

  composer why-not vendor/package ^9.0
  

  This usually points at a transitive dependency still pinned to Laravel 8.
• Config caching hides stale config. After publishing or editing package config, run php artisan config:clear (or config:cache in deploy) — otherwise Laravel 9 will serve the cached Laravel 8-era values and you'll debug a ghost.
• Auto-discovery can mask a missing manual registration. If the package wasn't discovered (e.g. cached packages.php), run php artisan package:discover and confirm the provider appears. On Laravel 9, php artisan about is the fastest way to confirm.
• Facade caching in tests. Facade::clearResolvedInstances() between tests if behavior leaks across test cases — a classic source of "works alone, fails in suite" on major upgrades.
• Extension points to prefer: the package's published config, its contracts/interfaces, and Laravel's container bindings. Avoid subclassing package internals — those are the first things to break in the next major.
• Lockfile review is mandatory. Treat the v9.0 bump as a dependency change: review composer.lock for cascading updates (especially symfony/* and illuminate/*), and run the full test suite plus a smoke test of the package's primary path before merging.