Getting Started

Treat v1.1.0 as a platform-compatibility release. Confirm your application runs Laravel 11 and PHP 8.2 or 8.3 before installing.
Do not plan adoption on Laravel 9 or PHP 8.1; v1.1.0 drops those platforms even though the package API is described as non-breaking.
Install with Composer using the package’s documented command, then follow its README for service-provider registration, config publishing, migrations, or asset publishing where applicable.
First use case: wire the package into one low-risk flow first—for example a single form submission, queued job, or read-only integration—so you can validate configuration, container bindings, and logging before expanding usage.
Read the package README and any upgrade notes alongside the v1.1.0 release notes; the release notes confirm compatibility changes but do not describe package-specific APIs or configuration.

Implementation Patterns

Prefer dependency injection over facades for package services so tests can swap implementations cleanly.
Keep package configuration in config/ with environment-driven values, and run php artisan config:cache during deployment to catch config mistakes early.
Isolate package side effects behind queued jobs or events where the package supports them, especially for external calls, notifications, or slow integrations.
Use Laravel’s test helpers and package-provided fakes where available; cover the integration point with feature tests rather than relying only on unit tests.
Add a CI matrix for PHP 8.2 and 8.3 on Laravel 11 to match the supported v1.1.0 platforms.
Upgrade workflow: create a branch, update Composer constraints, run composer update, clear cached config/routes, run the test suite, and smoke-test the integrated flow before merging.
If the package exposes extension points such as custom drivers, macros, events, or publishable config, prefer those over modifying vendor code.

Dropped Laravel 9 and PHP 8.1 support will usually appear as Composer resolution failures or platform check errors. Check composer.json, composer.lock, and CI images before debugging application code.
“No breaking changes” refers to the package API, not necessarily to your application’s platform upgrade path. Moving from Laravel 9/PHP 8.1 to Laravel 11/PHP 8.2+ can still expose framework-level differences.
Laravel 11’s slimmer application skeleton can affect provider registration, middleware, and config publishing. Follow the package’s Laravel 11 instructions if they differ from older examples.
After installing or upgrading, clear cached config, routes, and views; stale caches are a common source of “package not working” reports.
If bindings or config are not taking effect, verify provider registration order, published config filenames, and whether a cached config file is overriding local changes.
Use the package’s publish tags and documented extension points rather than editing vendor files. Keep customizations in app-level config, bindings, or decorators.
Because v1.1.0 release notes focus on platform support, verify package-specific config keys and behavior against the README before relying on assumptions from older Laravel versions.