Getting Started

Install with Composer and confirm the constraint resolves: 1.1.0 adds Laravel 13 support, so verify your composer.json allows laravel/framework: ^13.0 and that the package's own illuminate/* constraints line up.
Publish anything the package exposes before writing code: php artisan vendor:publish --provider="Vendor\Package\PackageServiceProvider". Read the published config top to bottom — it's the fastest map of the package's knobs.
Look first at the service provider. Bindings, config merges, publish tags, and command registration all live there, so it tells you the public surface in one file.
First use case: resolve the package's main class out of the container (or via its facade) in php artisan tinker or a throwaway route. Confirm wiring and config load before building features on top of it.
If you plan to extend or wrap the package, mirror its test setup — 1.1.0 moved to Orchestra Testbench, which is the right harness for package-level tests.

Implementation Patterns

Prefer constructor injection over facades. Bind the package contract in your own service provider and inject it; that keeps call sites swappable and trivially fakeable in tests.
Read config at resolution time (config('package.key') inside the method), not in a singleton's constructor, so config:cache and per-environment overrides behave predictably.
Decorate rather than fork. Wrap the package service in your own class implementing the same contract, delegate the happy path, and layer app-specific behavior on top. This survives upgrades.
Hook events instead of subclassing internals. If the package dispatches events, register a dedicated listener; it's the extension point least likely to break in a refactor.
Push package I/O onto queues from your own job classes wrapping the package call, so retries, backoff, and failure handling stay under your control.
In app tests, bind a fake or mock of the package contract in setUp() rather than hitting the real implementation.
Run a CI matrix across Laravel 12 and 13 while you migrate; the new constraint means both should be exercisable from the same branch.

Laravel 13 support is a compatibility change, not a behavior change. Re-run your full suite after bumping anyway — transitive dependency resolution can shift even when the package's own code is untouched.
Check the php constraint alongside the framework constraint. A Laravel 13 bump frequently raises the minimum PHP version, which can break CI images before it breaks code.
The lint/formatting churn in 1.1.0 makes diffs noisy. If you vendor or patch the package, rebase onto the release rather than re-applying formatting patches.
Any env() call inside the package's config file stops working after config:cache. Add a config:cache step to your deploy smoke test.
If you override a package binding, register yours after the package provider or use $this->app->extend(); registration order silently decides the winner.
Debugging is two commands: composer show vendor/package for the resolved version and its constraints, php artisan about for the framework/environment picture.
Stick to documented extension points — published config, contracts, events. A "refactor" release like this one can move internals without a major version bump, so code reaching into vendor/ is at risk on patch upgrades.
Testbench is the package's own test harness, not a stable public API. Don't build your app's tests on top of its helpers.