Laravel Http Macros Laravel Package

Product Decisions This Supports

• Build vs. buy vs. framework-native — conclusion unchanged. The real decision this package surfaces is whether to add a dependency to standardize HTTP client setup, or to write ~30–100 lines of in-house macro registration. Because Laravel's PendingRequest is already Macroable, "framework-native, thin in-house" remains the default answer — and this package is the evidence you'd cite when someone proposes a dependency for it.
• API integration consistency. If your product talks to Stripe, GitHub, a CRM, and three internal services, this pattern lets you declare named clients (base URL, auth headers, timeout, retry policy, Accept header) once and reuse them everywhere. That directly reduces per-integration drift and the class of bugs where one service call forgets a timeout or a user agent.
• Environment and multi-tenant routing. A config-driven macro registry makes it trivial to swap base URLs per environment, region, or tenant — useful if you're planning EU/US endpoints or white-label deployments.
• Testability roadmap. Standardized named clients pair well with Http::fake() scoping, supporting a "no unmocked outbound request in CI" policy — a security and reliability win that's easy to sell and easy to measure.
• Upgrade planning. If any part of the motivation is "macros are awkward on our Laravel version," the roadmap item is a framework upgrade, not a package adoption. Framing it that way keeps the dependency budget clean.
• Dependency-budget signal from 1.5.0. The release is framework-compatibility and housekeeping only: no new capabilities, no deprecations, no breaking changes. That tells you the project's release cadence is "keep it installable on new Laravel majors," not "grow the feature surface." Budget accordingly — do not put this on the roadmap expecting resilience features to arrive.

When to Consider This Package

Adopt the pattern almost always; adopt the dependency still rarely — but the risk calculus has softened, not hardened.

Revision to prior assessment: the earlier version of this note characterized the repository as archived with no future security patches. Release 1.5.0 (Laravel 13 compatibility, maintainer-authored PR #27) contradicts that — the package is being actively tracked against current and upcoming Laravel majors. The "archived / unsafe to depend on" risk line is withdrawn. The remaining concerns are low adoption and a single maintainer, which are vetting risks, not abandonment risks. Verify current star/dependent counts and repository status before quoting any number externally; the figures in the prior draft are no longer reliable.

Consider it (as a dependency) only if:

• You run several Laravel applications with duplicated, hand-rolled HTTP client setup and no shared internal package to put it in.
• You need a declarative, config-file-driven registry of endpoints rather than macro definitions scattered across service providers.
• You want that registry maintained by someone else across Laravel major upgrades and are comfortable with a one-maintainer bus factor.

Look elsewhere — or vendor the idea — when:

• You're on Laravel 9+. Http::macro() / PendingRequest::macro() in a dedicated service provider covers this in a few dozen lines with zero dependencies.
• The work is really SDK-shaped. Request/response classes, OAuth flows, pagination, retries, connectors → Saloon (with its Laravel integration) is the mature answer; OpenAPI-generated clients if you need typed contracts.
• The endpoint is on a critical path. Payments, auth tokens, PII. Not because the package is abandoned — it isn't — but because a single-maintainer, low-adoption dependency gives you no meaningful community vetting and no realistic path to a coordinated security response. MIT means you can fork, but only if someone owns that.
• You need resilience features — circuit breaking, backoff policies, per-host rate limits. 1.5.0 confirms these aren't coming; that's a different layer entirely.

Practical recommendation (unchanged): read the source, copy the ~100 lines of registration logic into App\Support\Http or a small provider (MIT permits it), and cite it in your internal conventions doc rather than in composer.json. If you do adopt it, pin the version, note the single-maintainer risk in your dependency register, and set a calendar reminder to re-evaluate at the next Laravel major.

How to Pitch It (Stakeholders)

To executives (one paragraph): We re-evaluated a small open-source utility for standardizing how our product calls external APIs. The pattern is worth adopting — it removes boilerplate, enforces consistent timeouts and headers, and makes outbound calls easier to test. The project is actively maintained and was just updated for the next Laravel version, which corrects our earlier assumption that it was abandoned; what remains true is that it has very little adoption and one maintainer, so it gives us no real safety net if something goes wrong. Recommendation: adopt the convention in-house, keep our dependency count unchanged, and spend the effort on an API-client standard we control. If engineering prefers the off-the-shelf version, it's now a defensible small bet rather than a red flag — just not a load-bearing one.

To engineering (the substance): 1.5.0 is a compatibility-only release: Laravel 13 support via PR #27, plus license-year and README image housekeeping. No API changes, no deprecations, no new features — nothing to migrate to, nothing to re-test beyond the Laravel 13 matrix. The package is still a thin layer over Illuminate\Http\Client\PendingRequest's macro support, letting you register named clients centrally. On Laravel 9+, Macroable already gives us this. Proposal: one HttpClientServiceProvider exposing named clients with baked-in base URL, auth, timeout, retry, and headers; a lint/test rule that fails CI on unmocked HTTP; and documentation of the convention. If the config-file registry ergonomics are appealing, either crib them from the source (MIT) or depend on it with a pinned version and a named owner.

Risk line to keep in the deck: actively maintained and tracking Laravel majors, but single-maintainer with minimal adoption — no community vetting, no credible path to a coordinated security fix. Safe to read, safe to depend on for non-critical paths, keep it off the payments/PII call graph.