Http Client Bundle Laravel Package

Product Decisions This Supports

• Not a build-vs-buy input for new work. This is an archived Symfony bundle with a single star, zero dependents, and no release since June 2022. It should not factor into build-vs-buy for any active roadmap item; adopting it is closer to a maintenance liability than a buy decision.
• Reference pattern, not a dependency. If your team is designing HTTP client observability (request logging, profiling hooks, client decorators) in a Symfony or Laravel codebase, the bundle's source can be read as a small worked example of how to wrap symfony/http-client events. Treat it as design inspiration only — do not add it to composer.json.
• Legacy inventory triage. The one legitimate PM use is answering "do we already depend on this?" during a dependency audit or pre-migration review. If any service lists it, that is a migration ticket, not a feature decision.
• Ecosystem signal, not a feature lever. Its abandoned state is evidence about the third-party HTTP-client tooling space: low adoption, no community maintenance, and a maintainer who moved on. That argues for owning this thin layer in-house rather than sourcing it.
• Platform mismatch disqualifier. Despite being surfaced in a Laravel context, this is a Symfony bundle (service container, bundle registration, Symfony HttpClient). It has no meaningful role in a Laravel product roadmap without a Symfony kernel present.

When to Consider This Package

Consider reading (not installing) it only when:

• You are on Symfony 4/5 with symfony/http-client and need a compact example of decorating clients, wiring event subscribers, or configuring per-client options — and you want a quick sanity check against a real, if tiny, implementation.
• You are doing archived-dependency archaeology, e.g. confirming what a stale composer.lock entry actually does before removal.
• You want a negative example for an internal RFC on why thin glue packages need an owner, tests, and a release cadence before being promoted to a shared internal library.

Look elsewhere — decisively — when:

• You are on Laravel. Different framework, different container, different HTTP abstraction. There is nothing to integrate.
• You need production support. Archived, MIT, no maintainer, no security response path. Any CVE in a transitive dep will be yours to fix, and you cannot upstream a patch.
• You need any modern PHP/Symfony version support. No release in over three years means no verified compatibility with current Symfony majors or PHP 8.3+.
• You need documented behavior or SLAs. One star and zero dependents means effectively no battle-testing, no issue history to mine, and no community to ask.
• You are comparing vendors or libraries for a procurement decision. This fails every standard criterion: maintenance, adoption, release recency, support.

How to Pitch It (Stakeholders)

For executives: We evaluated setono/http-client-bundle and recommend against adoption. It is an archived, single-maintainer Symfony bundle with one GitHub star, no downstream dependents, and no release since mid-2022. The direct cost of adopting it is near zero, but the carrying cost is a permanent fork-and-patch obligation for a component that saves us perhaps a day of engineering. If we need this capability, we build a small internal wrapper on top of the framework's native HTTP client — roughly one to two days of work that we own outright, with tests and a named maintainer. Recommendation: no-go; log as a known-abandoned package and remove it from any candidate lists.

For engineering: This is a Symfony bundle, not a Laravel package, so it is out of scope for the Laravel services regardless of its state. The code is small enough to read in an afternoon and does the standard thing — decorates symfony/http-client and exposes configuration through the bundle's DI extension. If we have a concrete need for HTTP client tracing/logging, lift the pattern, write our own subscriber, and test it against the Symfony versions we actually run. Do not pin an archived dependency for glue code we can own in a day. If it already appears in any composer.json, raise a ticket to remove it and replace with an in-repo implementation before the next framework upgrade.