Laravel Clickhouse Laravel Package

Getting Started

• Install with composer require <vendor>/<package>:^1.5 and confirm your app meets the new Laravel 5.8 baseline (laravel/framework:^5.8, PHP ^7.1.3).
• Start with the package README and composer.json to understand the supported Laravel/PHP matrix, then inspect the service provider and any publishable config.
• First use case: publish config if available (php artisan vendor:publish --provider="..."), wire the package into a single feature path, and verify with a focused feature test before rolling it out broadly.

Implementation Patterns

• Resolve the package through Laravel’s container rather than instantiating classes directly; this keeps facades, config overrides, and test doubles working.
• Keep package configuration in config/ and environment-specific values in .env; avoid editing vendor files or hard-coding credentials.
• If the package exposes events, jobs, or middleware, integrate it at the boundary of your domain: dispatch after your own transaction commits, and queue slow work where appropriate.
• Use Laravel’s testing helpers to assert integration behavior: container resolution, config publishing, facade calls, and any database/queue interactions the package touches.
• For multi-environment deployments, run php artisan config:cache and route:cache after confirming the package does not depend on runtime-only config reads.

Gotchas and Tips

• 1.5.3 raises the Laravel requirement to 5.8. Treat this as breaking for apps on Laravel 5.7 or earlier; pin ^1.4 until you can upgrade, and check transitive dependency conflicts with composer why-not.
• Laravel 5.8 is an old baseline. Confirm your PHP version, package discovery behavior, and any deprecated framework APIs before upgrading production.
• If package discovery is disabled, register the service provider and aliases manually; otherwise clear cached manifests after deployment.
• Debug integration issues with php artisan tinker, container resolution checks, and php artisan about/config:show where available; inspect storage/logs/laravel.log for provider boot failures.
• Extension points are usually config files, bound contracts, and published migrations/assets. Prefer overriding through those seams rather than subclassing vendor internals.