Connection Manager Laravel Package

Getting Started

• Confirm you are on Laravel 12 (php artisan --version) and PHP 8.2+ before adopting 1.0.4.
• Install with composer require <vendor>/<package>:^1.0.4; the release is a compatibility patch, so existing 1.0.x usage patterns should carry over.
• Look first at the package README, composer.json constraints, service provider, and any publishable config/migrations. In Laravel 12, auto-discovery should register the provider automatically.
• First use case: validate the package in a small Laravel 12 feature branch—one endpoint, job, or command—before rolling it across the app. This confirms the new framework support without committing to a broad migration.

Implementation Patterns

• Keep package configuration in config/<package>.php after publishing with php artisan vendor:publish --tag=<package-config>; avoid editing vendor files.
• Resolve package services through the container or facades rather than instantiating classes directly, so you can swap or mock them in tests.
• Wrap the package’s primary API behind a small application service or adapter. This keeps day-to-day calls consistent and isolates future package upgrades.
• Use the package in feature tests against Laravel 12’s test harness; assert that service provider registration, config merging, and any migrations behave as expected.
• For queues, events, or scheduled tasks exposed by the package, register them in your app’s standard AppServiceProvider, EventServiceProvider, or scheduler rather than relying on implicit package boot behavior.
• When upgrading from an earlier 1.0.x, update the Composer constraint to ^1.0.4 and run the full test suite on Laravel 12 before deployment.

Gotchas and Tips

• “Supports Laravel 12” does not guarantee every transitive dependency does. Run composer why-not laravel/framework 12 if installation conflicts appear.
• Clear cached config after publishing or upgrading: php artisan config:clear and php artisan cache:clear.
• If the package was manually registered in config/app.php, remove the duplicate registration and rely on Laravel 12 auto-discovery, or explicitly disable discovery for that provider.
• Pin the version in production (1.0.4) if you need stability; use ^1.0.4 only when you are comfortable with future patch releases.
• Debug registration and environment issues with php artisan about, package discovery output, and storage/logs/laravel.log.
• Extension points typically include published config, container bindings, and package events/macros. Prefer these over subclassing vendor code.
• No breaking changes are indicated in 1.0.4; treat it as a compatibility release and focus testing on Laravel 12 bootstrapping, provider discovery, and any deprecated framework APIs the package may still touch.