Getting Started

Require ^2.0 with Composer. Laravel auto-discovery should register the service provider, but verify the provider namespace in composer.json / vendor because 2.0.0 refactored namespaces and classnames.
Publish and diff config before using the package: php artisan vendor:publish --tag=<package-config-tag> (confirm the tag in the service provider). Do not blindly overwrite an existing config file; 2.0.0 explicitly requires config changes, so compare old and new keys and merge renamed values.
First use case: resolve the package’s main class through the container in a controller, command, or service rather than instantiating it directly. Confirm the new fully qualified classname from the package source or docs, then assert that config values load correctly.
Look first at the service provider (register/boot), the published config file, any facade accessor, and the package’s upgrade notes/changelog for renamed namespaces, classnames, and config keys.

Implementation Patterns

Prefer constructor injection or container resolution over static facades when upgrading. Facade classnames and underlying namespaces may have moved, so update typehints and imports together.
Centralize package configuration in the published config file and environment variables. After upgrading to 2.0.0, map old config keys to new ones in one place so application code does not depend on stale names.
If the package uses a manager/driver pattern, bind custom drivers or implementations in a service provider. Verify that extension registration APIs and expected interfaces still use the refactored namespaces.
Use the package inside queued jobs and Artisan commands by resolving it per handle() execution. This avoids stale config when config caching is enabled.
In tests, update imports, mocks, and assertions to the new classnames. Add a smoke test that boots the provider and resolves the main package class from the container after config is loaded.

2.0.0 is a breaking release: namespaces and classnames were refactored, and config changes are required. Before deploying, search the codebase for old namespace strings, facade aliases, class references, and config keys.
Clear caches after upgrading: composer dump-autoload, php artisan config:clear, php artisan cache:clear, and php artisan package:discover. In production, rebuild with php artisan config:cache only after verifying the new config.
Published config files are not updated automatically. Diff the package’s new vendor config against your app config and merge renamed keys deliberately.
If you registered class aliases in config/app.php, update them. Facades and aliases may have moved to new namespaces in 2.0.0.
Debug container errors by checking the provider’s bindings and the new fully qualified classnames. “Target class does not exist” usually means an old namespace survived in config, a facade alias, or a typehint.
Extension points may have moved with the refactor. Custom implementations should be checked against the new interfaces/namespaces, and any tagged services or driver bindings should be revalidated.