Getting Started

Confirm your app is on Laravel 12 and PHP 8.2+ before adopting 0.10.0; this release is primarily a framework-compatibility update.
Install with composer require <vendor>/<package>:^0.10 and let Laravel package discovery register the service provider. If discovery is disabled, add the provider manually.
Look first at the package README, composer.json, the service provider, and any publishable config. Those files tell you the supported Laravel constraints, entry points, and whether config/assets/migrations need publishing.
First use case: publish any config, resolve the package’s main service or contract from the container in a simple command or controller, and run a smoke test against Laravel 12. That validates installation, discovery, and configuration before deeper integration.

Implementation Patterns

Resolve the package through Laravel’s container rather than instantiating classes directly. Prefer constructor injection in controllers, jobs, commands, and listeners so the package can be swapped or mocked in tests.
If the package exposes a contract or facade, bind or alias it in a service provider and depend on the abstraction in application code. This keeps day-to-day usage clean and makes upgrades less invasive.
Keep package-specific configuration in config/ and drive environment-specific values through .env. Publish the config only when you need to override defaults, and keep overrides minimal.
Wrap package calls in a small application service or action class when the package is used from multiple places. That gives you one integration point for error handling, logging, retries, and future package changes.
Use the package’s own test helpers or fakes where available, and add at least one feature test that exercises the real integration path on Laravel 12. For queued work, test the job with the package dependency resolved from the container.
In CI, test against the Laravel 12 constraint declared by the package. If you support multiple Laravel versions, keep a matrix that includes the oldest supported version and Laravel 12.

0.10.0 is still pre-1.0. Treat minor releases as potentially breaking even when the release notes only mention added framework support. Pin to a minor range and review the changelog before upgrading.
Laravel 12 requires a newer PHP baseline. Check composer.json for the package’s PHP constraint and make sure your runtime and CI images match.
After installing or upgrading, clear cached config and routes (php artisan config:clear, route:clear, optimize:clear). Stale cached config is a common reason a newly supported Laravel version appears not to work.
Verify package discovery is active. In applications that disable discovery or use a custom bootstrap, the package may install successfully but not register its provider.
If the package publishes migrations, assets, or config, publish them explicitly and review the published files before committing. Avoid editing vendor files.
Debug integration issues by checking the provider registration, published config, and the package’s own test suite first. If the package exposes events, macros, or bindable contracts, those are the preferred extension points over subclassing internals.
Do not depend on undocumented internals while the package is below 1.0; they are the most likely to change in the next compatibility release.