Laravel Auto Morph Map Laravel Package

Getting Started

• Confirm the baseline first. The 9.0.0 release notes say only "Laravel 9 first version," which tells you this package versions its major line in lockstep with Laravel. Install with composer require <vendor>/<package>:^9.0 and verify composer why-not laravel/framework 9.* comes back clean before you write any code.
• Check the platform requirements. Laravel 9 requires PHP 8.0+, so confirm your app and CI images are already on 8.0/8.1. The package's own composer.json is the authoritative source for its PHP, Illuminate, and Symfony constraints — read it rather than trusting the one-line release note.
• Register and publish. Run php artisan vendor:publish --provider="<Vendor>\<Package>\<PackageServiceProvider>" (add --tag=config, --tag=migrations as applicable). Commit the published config to version control so environment differences are explicit. Run php artisan migrate if the package ships migrations.
• Where to look first, in order: the package's composer.json (constraints), its CHANGELOG.md/upgrade guide (the release note is too terse to be your only source), the service provider (what it binds, aliases, and publishes), then the config file (the real API surface for most packages).
• First use case: wire the package into a single, low-risk path — a console command or a throwaway route — and resolve it from the container. Confirm it boots, that its config is read, and that its facade (if any) resolves. Only then move it into a real feature.

Implementation Patterns

• Pin major-to-major and upgrade in the right order. Bump laravel/framework to ^9.0 first, run your test suite green, then bump the package to ^9.0. Attempting both at once makes a failure impossible to attribute.
• Inject, don't facade, in domain code. Resolve the package's contract/interface via constructor injection rather than calling its facade statically. This keeps your unit tests free of a booted application and makes it trivial to swap in a fake.
• Treat the published config as your integration layer. Most of a package's day-to-day behaviour is tuned through config, not code. Drive it from env() in the config file only — never call env() outside config, especially once config:cache is in play.
• Queue and command usage. If the package does I/O (HTTP, files, search), wrap calls in jobs and inject the package into handle(). Keep the serialized job payload free of package internals; resolve them at execution time so retries pick up fresh config.
• Test with the package's own fakes. If it ships Package::fake() or a swap-able binding, use it in feature tests. If it doesn't, bind a mock to its interface in a test service provider — that's the supported extension point.
• CI matrix. With Laravel 9's PHP 8 requirement, run at least 8.0 and 8.1 in CI, plus your lowest supported Laravel patch. This catches the constraint drift that a one-line release note won't tell you about.

Gotchas and Tips

• The release note is a red flag, not documentation. "Laravel 9 first version" implies a major bump — majors conventionally carry breaking changes. Read the actual changelog/upgrade guide and diff the public API before adopting. If no upgrade guide exists, treat that as a maturity signal and pilot the upgrade on a branch.
• Dropped Laravel 8 support is the likely breaking change. Expect ^9.0 to have removed illuminate/*:^8.0 from its constraints. Any app still on Laravel 8 cannot take this release; plan the framework upgrade as a prerequisite, not an afterthought.
• Config caching bites on closures. If the published config contains closures or reads env() at runtime, php artisan config:cache in production will silently break it. Test with config:cache enabled, not just locally.
• vendor:publish --force overwrites your edits. After the first publish, stop re-publishing. Instead, diff the package's new config against yours during upgrades and merge deliberately.
• Facade/alias resolution failures after a major bump usually mean the provider isn't registered (Laravel 9's package discovery can be disabled or cached) or an alias moved. Run php artisan package:discover and php artisan optimize:clear before debugging deeper.
• Debugging technique: use app()->make(Interface::class) in php artisan tinker to prove the binding exists, then composer why-not to prove the constraints resolve. Those two commands answer the majority of "package won't load" questions.
• Extension points to prefer: rebinding the package's interface in your own provider, listening to the events it dispatches, and subclassing its macroable classes. Avoid editing vendor code or forking for small behaviour changes — forks become painful at the next major.