Driver Kik Laravel Package

Getting Started

This release (1.1.0) is the first Laravel-native integration point: the package now ships a Service Provider, so it can be auto-discovered and bootstrapped by the framework rather than wired up by hand.

Minimal steps:

1. composer require <vendor>/<package> — with Laravel package discovery enabled (default in Laravel 5.5+), the provider registers automatically; no config/app.php edit needed.
2. Check composer show <vendor>/<package> and read the package's composer.json extra.laravel.providers block to confirm which provider(s) are registered and whether a facade alias is exposed.
3. If the package publishes assets, run php artisan vendor:publish --provider="Vendor\Package\PackageServiceProvider" and inspect config/<package>.php before touching code.
4. First use case: resolve the package from the container rather than instantiating it — app(\Vendor\Package\Client::class) or the documented facade — so you inherit whatever the provider binds (config, HTTP client, credentials).

Where to look first: the provider's register() and boot() methods. In a package this small, those two methods are the entire integration surface and tell you more than the README about what is bound, what is deferred, and what is published.

Implementation Patterns

Constructor injection over facades. With a provider in place, the package's main class should be resolvable from the container. Type-hint it in controllers, jobs, and console commands; let the container supply the configured instance. This is the pattern that makes the package testable and swappable.

Config-driven instantiation in a dedicated binding. If the provider registers a singleton using config values, treat that config file as the seam. Override values per-environment in .env rather than editing the published config, and in tests use config()->set() inside the test before resolving the class.

Deferred providers for hot paths. If the package is only used in a handful of endpoints, confirm whether the provider implements DeferrableProvider. If it does not and boot cost is measurable, wrap usage behind your own lazily-resolved service rather than calling the package on every request.

Testing. Because the provider is now registered, RefreshDatabase-style integration tests get the real bindings for free. For unit tests, bind a fake into the container ($this->app->instance(...)) instead of mocking the concrete class — the provider's binding is the contract.

Queued work. If the package's client is not serializable, do not inject it into a job's constructor; resolve it inside handle() so the container builds it fresh in the worker, with the correct config for that environment.

Multi-package composition. If you already wrap this package in your own service class, keep the wrapper and let the provider handle the inner construction. Do not re-register the provider manually in AppServiceProvider — duplicate registration causes double boot() side effects (double publishing, duplicate listeners).

Gotchas and Tips

• Discovery caching. After upgrading, run php artisan package:discover (or composer dump-autoload) and php artisan config:clear. A stale bootstrap/cache/packages.php is the most common reason "the provider isn't registering."
• Two registration paths. Older Laravel versions and manually-registered apps will not use auto-discovery. If you add the provider to config/app.php and discovery is on, boot() runs twice. Pick one.
• register() vs boot() mistakes. Config merges and container bindings belong in register(); publishing, routes, and event listeners belong in boot(). If a config value appears empty, check whether the package reads config in register() before mergeConfigFrom() has run.
• Published config drift. Once published, config/<package>.php no longer tracks package defaults. New keys added in later releases will silently be null — diff the package's config against yours on every minor upgrade.
• Facade aliases are global. If the package registers an alias like Package, it can collide with an application class of the same short name. Prefer full class imports in new code.
• Debugging registration. php artisan about (Laravel 9+) and php artisan tinker with app()->getLoadedProviders() confirm whether the provider is actually loaded before you debug anything inside it.
• Extension point. If you need to customise the binding, use $this->app->extend() in your own AppServiceProvider::register() rather than overriding the package's provider — it survives package upgrades.
• Version pinning. This is the first release with framework integration; pin ^1.1 and read the 1.2 diff for changes to the provider's bindings, which are effectively part of the public API from here on.