Http Client Bundle Laravel Package

Product Decisions This Supports

• Framework mismatch check (decide first): This is a Symfony bundle, not a Laravel package. It only makes a decision relevant if we run Symfony services; for a Laravel codebase it supports no decision beyond "close the tab." Flagging this early avoids a wasted spike.
• Build vs. buy for the outbound HTTP layer: The package is a thin integration shim — it wires an existing http-client implementation into Symfony's DI container (service definitions, bundle config, autowiring). It does not add retries, circuit breaking, caching, or observability we couldn't get elsewhere. So the real decision is "do we standardize on weblabel/http-client?" — and if the answer is no, this bundle is irrelevant.
• Roadmap fit: Low. Zero stars, zero dependents, last release 2021-12-08, opportunity score 22.8. Treat it as a pattern reference (how to expose a PSR-18 client as a Symfony service) rather than a dependency to schedule.
• Use cases it would cover: A Symfony 4/5-era app that already depends on Weblabel's HTTP client and wants container-managed clients with per-integration configuration (base URI, auth headers, timeouts) instead of new Client() scattered through services.
• Laravel equivalent decision it does inform: In Laravel, the same need is already solved by the Http facade / Guzzle with config/services.php + a singleton binding. That's a 20-line service provider — the build-vs-buy math never favors pulling in an unmaintained third-party bundle here.
• Vendor-risk register: Any adoption becomes a "we own this code" entry — MIT license makes forking permissible, but we'd absorb maintenance indefinitely.

When to Consider This Package

Consider it only if all of these hold:

• The service is Symfony (not Laravel, not plain PHP).
• We have already committed to weblabel/http-client for another reason (existing Weblabel estate, vendor mandate).
• We're on the PHP/Symfony versions that package targets (roughly PHP 7.x / Symfony 4–5 era) and aren't planning an upgrade in the next 12 months.
• We're comfortable vendoring or forking — assume upstream is dormant.
• The scope is internal, non-critical traffic, not payments, auth, or anything with an SLA.

Look elsewhere when:

• Laravel: use the built-in Http facade / Guzzle with a singleton binding and config/services.php. No third-party needed.
• Symfony: use symfony/http-client with framework-native framework.http_client.scoped_clients configuration — actively maintained, first-party, and covers the same scoped-client use case this bundle provides.
• You want PSR-18/PSR-17 portability: php-http/discovery plus any compliant client gives you the same decoupling with a live ecosystem.
• You need resilience features (retry, backoff, circuit breaker): neither this bundle nor its underlying client is the right layer; use a client with middleware (Guzzle handlers, symfony/http-client + RetryableHttpClient) or a service mesh.
• Any security/compliance review is in scope: no releases since Dec 2021, no visible adoption, no dependents — you cannot lean on the community to catch CVEs upstream.

Recommendation: Decline adoption. Log it as a rejected candidate with the rationale "unmaintained, zero adoption, superseded by first-party framework HTTP clients." Revisit only if a Weblabel dependency already forces the underlying client into our stack.

How to Pitch It (Stakeholders)

To executives (one paragraph): We evaluated a small open-source add-on that plugs an HTTP client into the Symfony framework. It is a convenience wiring layer, not a capability — it adds no features we don't already get from the frameworks we use. It has no users, no dependents, and no release since December 2021, so adopting it would mean we quietly take on ownership of unmaintained code. Recommendation: do not adopt. We'll use the HTTP clients built into Laravel and Symfony, which are maintained by those projects and already cover the same need. Cost avoided: an indefinite maintenance tail plus a future migration off a dead dependency.

To engineering (the short version): It's a Symfony bundle that registers an http-client service in the container. MIT licensed, so forking is legal, but there's no upstream activity to rely on and nothing here you can't do with framework.http_client.scoped_clients (Symfony) or a one-file service provider around Guzzle (Laravel). If we ever need scoped, per-integration clients: configure them natively, keep the client interface behind our own port, and we retain the option to swap implementations without touching call sites. If someone on the team already depends on weblabel/http-client, vendor the bundle and pin the commit — but don't let it become the standard.