Guzzle5 Adapter Laravel Package

Product Decisions This Supports

• Legacy compatibility vs. modernization roadmap. This package answers a scoping question: do we spend engineering cycles forcing downstream users off Guzzle 5, or do we ship a thin bridge and defer that migration? It is an enablement tool for the latter.
• Build vs. buy for an HTTP abstraction layer. If our libraries depend on php-http/client-implementation, this is a ready-made adapter that converts our PSR-7 requests to Guzzle 5 and back, rather than us writing and maintaining that translation logic.
• Dependency support-matrix decisions. It informs which HTTP clients our SDKs/packages can officially claim compatibility with, and whether "Guzzle 5" stays in that matrix for another release cycle.
• Sunset and deprecation planning. Because the package is archived (last release Feb 2019), it is a signal to schedule the end of Guzzle 5 support rather than treat it as a permanent dependency.
• Enterprise/legacy-customer retention. For accounts or integrators pinned to an old stack, offering this route can unblock adoption without demanding a platform upgrade.
• Not a feature decision. This package adds no user-facing capability; it is purely an interoperability decision with maintenance and security implications.

When to Consider This Package

Consider it only when all of the following hold:

• You maintain or consume a library that requires php-http/client-implementation (HTTPlug), and a meaningful share of users are still on Guzzle 5.
• You need a short-term bridge to onboard those users without a forced major-version upgrade.
• The target environments still run a PHP version Guzzle 5 supports, and there is no compliance requirement forbidding an archived dependency.
• The conversion scope is limited to what the adapter covers: PSR-7 ↔ Guzzle 5 messages and exception translation — not advanced features like async pooling, middleware, or stream handling.

Look elsewhere when:

• Maintenance or security posture matters. The package is archived, has ~10 stars, a low health score, no listed repository, and no releases since 2019 — there is no upstream to patch, audit, or get support from. This is a supply-chain risk in any regulated or security-scanned environment.
• A modern path exists. Prefer Guzzle 6/7 with the maintained HTTPlug adapter, or standardize on PSR-18 clients, which is where the ecosystem moved.
• You are starting greenfield or already on PHP 8+, where legacy Guzzle 5 support is a net liability.
• You need long-term support or vendor accountability, both of which an archived package cannot provide.

How to Pitch It (Stakeholders)

To executives: This is a low-cost, low-risk bridge, not a strategic investment. It lets customers on older Guzzle 5 stacks use our libraries without a disruptive upgrade, protecting adoption and revenue in the near term. The trade-off is real but bounded: the component is unmaintained (archived since 2019), so it should be treated as a time-boxed compatibility shim with an explicit exit date, not a permanent platform commitment. Recommendation: approve short-term use while funding a migration path to a supported HTTP client.

To engineering: It implements the HTTPlug HttpClient interface and does the mechanical translation — PSR-7 requests into Guzzle 5 requests, responses back to PSR-7, and Guzzle exceptions into HTTPlug exceptions — via a single Composer dependency. It solves the integration plumbing so we don't hand-roll it. Caveats to own: no listed repository to fork or audit, no releases since 2019, and no upstream maintenance. Pin the version, wrap it behind our own client interface so it's swappable, and pair adoption with a tracked migration to Guzzle 6/7 or PSR-18.