Getting Started

Confirm your app targets Laravel 10 and PHP 8.1+ before installing v2.0.0; this is a major release whose headline change is Laravel 10 readiness, so treat it as an upgrade milestone rather than a drop-in patch.
Install with composer require <vendor>/<package>:^2.0 and review the package’s composer.json constraints to verify it no longer supports older Laravel/PHP combinations you may still rely on in CI or local tooling.
Publish any package config with php artisan vendor:publish --provider="<Vendor>\\<Package>\\<Package>ServiceProvider" and inspect the defaults before writing application code.
First use case: wire the package into a single, low-risk feature (for example one controller or one queued job) and run the package’s own tests plus your app’s test suite. This validates Laravel 10 compatibility in context before rolling it across the codebase.

Implementation Patterns

Prefer constructor injection or Laravel’s service container over facades in application code. This keeps the package easy to fake in tests and reduces coupling if the v2 API changes again.
Isolate package usage behind a small application-level service or adapter. When a major release changes method signatures or config keys, you update one adapter instead of dozens of call sites.
Use the package’s config file as the integration contract: keep environment-specific values in .env, and run php artisan config:cache in deployment to catch config-related regressions early.
If the package exposes jobs, events, or listeners, integrate them through Laravel’s queue and event system rather than calling package internals directly. This lets you test and retry integration points independently.
In tests, use the package’s provided fakes or bind a mock implementation into the container. For v2 upgrades, add a regression test that exercises the package’s primary happy path under Laravel 10 before merging.
For multi-environment deployments, pin ^2.0 in composer.json and verify the lock file is updated consistently across local, CI, and production. Avoid floating dev-main constraints while validating a new major.

“Prepare for Laravel 10” often means dropped support for older Laravel and PHP versions. Check composer.json require constraints and your CI matrix; an app still on Laravel 9 or PHP 8.0 will fail dependency resolution.
Major version bumps can include silent breaking changes not obvious from the release title. Read the package’s UPGRADE/CHANGELOG and compare public APIs, config keys, and published assets before upgrading.
Laravel package auto-discovery can mask service provider registration issues. If behavior differs between local and production, run php artisan package:discover and clear cached bootstrap files.
Config caching will ignore changes made directly to config/<package>.php at runtime. Always update .env or config values through deployment configuration, then recache.
If the package registers migrations, publish them explicitly and review them for Laravel 10 schema compatibility. Avoid relying on package migrations running automatically in production.
Use the package’s extension points — custom drivers, macros, events, or binding overrides — instead of editing vendor files. This keeps future major upgrades tractable.
When debugging, enable package-specific logging if available and reproduce with APP_DEBUG=true in a non-production environment. For queue-related integrations, run a single worker with --once to isolate failures.