Httplug Pack Laravel Package

Product Decisions This Supports

• HTTP-client abstraction strategy. This package exists to answer one question cheaply: do we code against an HTTP interface, or against a concrete client? Adopting HTTPlug (the abstraction) versus calling Guzzle directly is a real architectural decision with downstream cost — it determines how painful a client swap, a retry/caching middleware insertion, or a test double becomes. The pack is only the "install opinion" that makes that decision a one-line change in Symfony apps.
• Build vs. buy (and the honest answer: neither). The pack is a thin Composer meta-package — under Symfony Flex it isn't even installed; Flex expands it into its constituent requirements (httplug, message, a client adapter). The "build" alternative is three lines in composer.json. So the decision this informs is "do we adopt the abstraction?", not "do we adopt this package?" A PM should not spend a buy/build cycle here; a tech lead should spend 30 minutes.
• Stack/roadmap scoping. It is Symfony Flex-specific. For a Laravel-first roadmap it is effectively out of scope — Laravel ships Illuminate\Http\Client over Guzzle and does not consume Flex recipes. Its value as a signal is negative: it tells you the team is maintaining a Symfony footprint that needs separate dependency governance.
• Migration and deprecation planning. Last release 2019-04-08 maps to the Symfony 4 / Guzzle 6 / HTTPlug 1.x era. HTTPlug 2.0 became a superset of PSR-18, and Symfony's own HttpClient plus PSR-18 auto-discovery displaced this pattern. Using this package is a marker that an app is on a pre-PSR-18 HTTP layer — useful input for a modernization epic and its estimate.
• Vendor-risk / dependency register. 38 stars, 0 dependents, no release in ~6 years. That combination is the textbook profile of an unmaintained transitive convenience package. It belongs in the risk register as "pin explicitly, do not rely on," not in the "strategic dependency" column.
• Testability argument. The strongest PM-usable benefit of the HTTPlug family is php-http/mock-client: it lets you assert on outbound HTTP calls without network access. That is a plausible line item in a quality/CI initiative ("HTTP boundary is mockable") — but it is an argument for the abstraction, not for this recipe.
• Use cases where it earns its keep: a shared PHP library that must not force a client on consumers; a Symfony 4 service that wants a working, swappable HTTP stack in one composer require; a team standardizing on HTTPlug-era middleware.

When to Consider This Package

Consider it when all of these hold:

• The application is Symfony 4.x with Flex and you want a functioning HTTP client plus message factories plus adapter installed and auto-configured in one command.
• You specifically want client-agnostic HTTP — the ability to swap Guzzle for another PSR-7/PSR-18 implementation without touching call sites.
• You are publishing a library that consumes HTTP and refuse to impose a concrete client on downstream users.
• You want mock-client-based testing of the HTTP boundary out of the box.
• The codebase is already frozen on that era and you are deliberately not modernizing yet.

Look elsewhere when any of these hold:

• Laravel. Use Http:: / Guzzle directly; Flex recipes are inert. Adopting this adds a dependency for zero runtime effect.
• Greenfield work. Go straight to PSR-18 (psr/http-client) and/or symfony/http-client, which have native auto-discovery and active maintenance. HTTPlug's interfaces are the predecessor, not the destination.
• Maintenance guarantees matter. No release since April 2019, zero dependents, one maintainer org. Expect no fixes; you own the pins.
• You already have Guzzle configured. The marginal value collapses to "a second abstraction layer over the client you already use."
• You want visibility into what you're installing. Because Flex unpacks it, the pack's own composer.json is invisible in the lockfile — the transitive pins become yours to audit and upgrade.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a low-cost, low-risk convenience package, not a strategic bet — it is a one-command installer for an HTTP-client abstraction in Symfony applications. It costs essentially nothing to adopt and nothing to skip. Because it has had no release since 2019 and no downstream dependents, I do not recommend adding it to any active product; where a Symfony service already relies on it, we should keep it running but schedule a move to the industry-standard PSR-18 interface during the next maintenance window. No budget, headcount, or roadmap change is implied.

To engineering (the substance): It is a Symfony Flex "pack" — a virtual package whose only job is to pull httplug, the message factories, and a client adapter, and let Flex wire them. It buys you a swappable HTTP boundary and a mock client for tests; it costs you an unpinned, unmaintained transitive layer and a pre-PSR-18 interface. Recommendation: don't add it; replicate it. Put the three explicit requirements in composer.json, pin them, and target PSR-18 for anything new. If a service is already on HTTPlug, that is fine — treat it as a known legacy surface and migrate when the client adapter next needs touching. Track it in the dependency register as "unmaintained, no action required, no new adoption."