Getting Started

Require use-lock/client-laravel:^0.3; this release pulls in use-lock/client-php:^0.2.
Publish the package config (php artisan vendor:publish --provider="UseLock\Client\Laravel\LockServiceProvider" or the package’s publish tag) and set credentials in .env.
Look first at config/lock.php and the package service provider to confirm the container binding and config keys.
First use case: inject the Lock client into a controller or queued job and make a single read call to validate credentials and response shape.

Implementation Patterns

Prefer constructor injection of the bound client/interface over resolving it from the container inline.
Keep Lock calls in dedicated service classes or actions; avoid calling the client directly from Eloquent models or config files.
For multi-tenant or per-user credentials, use the package’s client factory/scoped instance rather than mutating global config at runtime.
Put write operations behind Laravel queues when they can be retried; add your own retry/backoff if the client does not provide it.
In tests, bind a fake implementation or mock the underlying HTTP layer so tests do not depend on live Lock credentials.
If the package exposes a facade, use it sparingly (e.g. Blade/views) and prefer injection elsewhere for testability.

0.3.0 is primarily a dependency alignment to use-lock/client-php 0.2. Treat the underlying SDK as potentially breaking: run composer update use-lock/client-laravel use-lock/client-php, then run integration tests and check the client-php changelog for method/response changes.
After changing credentials in .env, run php artisan config:clear locally and php artisan config:cache in production.
Avoid resolving the client during config loading or model boot methods; it can break config:cache and cause hard-to-trace boot failures.
Confirm the resolved dependency version with composer why use-lock/client-php; pin "use-lock/client-laravel": "^0.3" and avoid overriding the transitive client-php constraint.
For debugging, log request IDs or response metadata from the client, and enable any package debug logging if available.
Extension point: bind your own wrapper/decorator in a service provider if you need custom retries, logging, or middleware around the client.