Laravel Planetscale Laravel Package

Getting Started

• Confirm the version constraint first. v1.1.0 is a compatibility release: the headline change is Laravel 10.x support. Run composer require <vendor>/<package>:^1.1 and verify composer.json resolves illuminate/support to ^10.0 — on Laravel 9 you can stay on the 1.0 line, but do not assume a single constraint covers both.
• Check the PHP floor. Laravel 10 requires PHP 8.1+, so this release effectively raises your runtime baseline. Confirm your CI matrix and any polyfilled environments before upgrading; a green composer update on 8.0 is not possible here.
• Look first at the package's service provider and config/ directory. Standard Laravel packages expose their surface there — that is where you learn which bindings are container-resolved, which are facades, and which settings are publishable versus read-only.
• Publish and commit config before writing feature code. php artisan vendor:publish --provider="Vendor\Package\PackageServiceProvider" --tag=config (adjust the tag to whatever the package documents). Commit the published file so environment-specific overrides are visible in review rather than hidden in vendor defaults.
• First use case: wire the package into a single, low-risk path — one controller action or one queued job — and confirm it resolves from the container. A successful app(YourFacade::class) call plus one real request is a better smoke test than reading the README twice.

Implementation Patterns

• Constructor injection over facades in application code. Resolve the package's contracts through the container so tests can swap implementations; reserve facades for Blade templates and tinker sessions where brevity wins.
• Config-driven behavior, not hardcoded calls. Most Laravel packages read from config/<package>.php at boot. Set per-environment values in .env and reference them from the published config rather than branching on app()->environment() in your own code.
• Wrap third-party calls behind a thin application-level service. One App\Services\... class that owns the package dependency keeps the blast radius of a future major version to a single file and gives you an obvious seam for fakes.
• Test with the package's fakes if it ships them. Packages that touch HTTP, queues, or the filesystem commonly provide Package::fake() plus assertion helpers. Prefer those over Http::fake()/Queue::fake() unless the package is thin enough that a generic fake is equivalent.
• Use events and jobs as the integration boundary. If the package dispatches events or exposes queueable work, hook your listeners there instead of subclassing package internals — subclassing is the fastest route to a painful upgrade.
• Pin in CI, float in local. Keep ^1.1 in composer.json but run your test suite against the lowest and highest resolvable versions (e.g. a CI matrix across Laravel 10.x minors) so a future patch release can't silently break you.
• Register any package migrations and commands explicitly in the review checklist. Laravel 10's auto-discovery is reliable, but migrations and scheduled tasks still need a human to confirm they ran where expected.

Gotchas and Tips

• Do not read v1.1.0 as a feature release. The only documented change is Laravel 10.x support. There is no new API surface to adopt — treat the upgrade as a compatibility exercise and diff the package source between 1.0 and 1.1 if you need certainty about undocumented changes.
• Auto-discovery is cached. After upgrading, run php artisan package:discover (or composer dump-autoload) — a stale bootstrap/cache/packages.php is the usual cause of "class not found" immediately after a version bump.
• Clear config cache after publishing. php artisan config:clear — edits to a published config file are invisible while a cached config is in play, and this burns people most often in staging.
• Watch for transitive Laravel constraint conflicts. If another dependency still caps at ^9.0, Composer will refuse the upgrade. composer why-not illuminate/support 10 localizes the culprit faster than reading the resolution error.
• Laravel 10 removed previously deprecated framework APIs. If the package touches schema modification or anything that historically leaned on doctrine/dbal, verify column-change behaviour on a copy of a real database before trusting it in production.
• Extension points to prefer: published config, container bindings against the package's interfaces, and its documented events. Everything else — protected methods, internal traits, vendor/ patches — should be treated as private and will not survive the next minor release.
• Debugging tip: when a package call fails opaquely, app()->bound(YourClass::class) and app()->make(YourClass::class) in tinker isolate whether the problem is registration or behaviour. Registration failures are almost always cache, provider, or constraint related — rarely the package itself.