- How do I install kozz/laravel-guzzle-provider?
- Install it with Composer by requiring kozz/laravel-guzzle-provider in your project. The package ships a Laravel service provider that is typically registered through package auto-discovery, so no manual entry in config/app.php is needed on Laravel 5.5 and later. After installing, optionally run php artisan vendor:publish to get the configuration file into config/ so you can adjust client defaults. Then simply type-hint GuzzleHttp\Client anywhere the container resolves your classes.
- Does this package support Guzzle 7 and Laravel 9, 10, or 11?
- The package is branded for Guzzle 5/6, while Laravel 9 and newer pull guzzlehttp/guzzle ^7.2 transitively through Illuminate\Http\Client. That means adoption only works if the package's composer.json guzzlehttp/guzzle constraint has actually been widened to allow ^7, so check the require block rather than the release date. A recent tag on a repo whose README still advertises Guzzle 5/6 may be a metadata bump rather than a genuine compatibility release. Verify PHP 8.1+ compatibility of the resolved Guzzle major and confirm the provider doesn't call Laravel APIs removed in 10/11 before committing.
- How do I configure the Guzzle client's defaults, such as base_uri and timeout?
- Publish the package config file with php artisan vendor:publish, then edit the array of Guzzle client options it exposes. The provider merges that config when it registers the singleton, so values like base_uri, timeout, headers, and verify apply to every client resolved from the container. Because the options are merged once at binding time, changing config at runtime after the singleton is resolved will not affect the already-constructed client.
- How do I inject the Guzzle client into my classes?
- Type-hint GuzzleHttp\Client in a constructor or method signature and let Laravel's container resolve it. The provider registers the client as a singleton, so the same instance is reused for the whole request lifecycle. This is idiomatic service-locator style Laravel wiring, but it gives you no interface boundary, so consider depending on your own ApiClient interface instead if you want to keep call sites swappable.
- Is the Guzzle client a singleton, and is shared state a problem in queue workers or Octane?
- Yes, the provider registers a single container-cached client instance, which is convenient but invites accidental shared state. In long-lived processes such as queue workers and Laravel Octane, headers set on the client for one job can leak into the next request, which is a classic symptom of mutated singletons. Prefer passing per-call options to each request method, or clone the client, rather than mutating shared defaults at runtime.
- Should I use this package or Laravel's built-in HTTP client?
- Since Laravel 7, Illuminate\Support\Facades\Http wraps Guzzle with retries, timeouts, test fakes, and macros, which is a superset of what this package provides for most call sites. Reach for the built-in client first, and only consider a raw GuzzleHttp\Client where you need streaming, custom handlers, or curl tuning. In those cases a hand-written provider of roughly 15 to 25 lines in app/Providers is equivalent to this dependency and fully under your control.
- Does the package support retries, per-endpoint clients, or circuit breakers?
- No. It is a thin composition layer that wires a client into the container, not an HTTP governance layer, so retry policy, circuit breaking, and per-service base_uri configuration are outside its scope. If you need different clients per upstream API, define your own factory or ApiClient interface and construct configured Guzzle instances inside it. That also keeps consumers decoupled from the package namespace, making it a swap-in implementation detail.
- How do I log Guzzle requests and responses with this package?
- The provider typically wires Guzzle's logging subscribers into Laravel's event dispatcher, giving you request and response visibility through your existing log channels. If you don't use that wiring, or you need timing data, correlation IDs, and structured context, you lose observability your own middleware would otherwise provide. Many teams add a custom middleware or subscriber on top so that outgoing calls carry a request ID propagated from the incoming request.
- Is the package actively maintained, and what are the alternatives?
- The repository has a small footprint, roughly 62 stars and no dependents, which means essentially no production feedback loop to surface breakage before you hit it. Bus factor is one, so treat it as unmaintained until proven otherwise. The strongest alternatives are Laravel's built-in HTTP client, a first-party service provider you own, or a dedicated Guzzle wrapper library that is actively released against Guzzle 7.
- How do I test code that depends on the injected Guzzle client?
- Because the client is resolved from the container, you can swap it in tests with $this->app->instance(GuzzleHttp\Client::class, $mock) or bind a client configured with Guzzle's MockHandler. If your classes depend on an interface you own rather than the concrete client, faking becomes simpler and does not couple your test suite to this package. Note that swapping the singleton only works if nothing in your code captured the client before your test rebinds it.