Laravel Http Macros Laravel Package

Technical Evaluation

Architecture fit

• Unchanged from the prior assessment: the package is a thin macro layer over Illuminate\Http\Client, registering closures on Laravel's Macroable HTTP client. No service provider wiring beyond auto-discovery, no config, no drivers. Lowest-friction integration shape available.
• Fits applications that standardize outbound calls through the Http facade. Does not fit applications with a bespoke HTTP gateway where macros would be bypassed.
• Architectural concern stands: macros are global mutable state. Name collisions with first-party or other vendor macros are silent — last registration wins.

Integration feasibility

• Still trivial to install and adopt; a developer is productive in under an hour.
• Materially improved: 1.5.0 adds Laravel 13 compatibility, which means the illuminate/support constraint has been widened. The prior assessment's central integration blocker — an archived package's Composer ceiling blocking a framework major — no longer applies for teams targeting Laravel 13.
• The previously flagged metadata discrepancy is now resolved in the package's favor: the anomalous 2026-03-19 date was not a data artifact. The repository was active, not archived. The "archived" premise in the prior assessment should be considered retracted pending re-verification on Packagist/GitHub, and the archived flag in whatever inventory surfaced it needs correcting.

Technical risk

• Archived-status risk is withdrawn; bus-factor risk replaces it. Every substantive change in this release traces to a single human maintainer (@andrey-helldar); the remainder are bot-driven housekeeping commits (LICENSE year, banner, logo, preview). Effective bus factor is 1. The package is maintained, but not redundantly maintained.
• Surviving a Laravel major is a positive signal. Shipping L13 support implies the macros were exercised against a new framework major, which is exactly the failure mode we were most worried about (macros reaching into PendingRequest internals). This raises confidence that the macros use public API — but it is inference, not proof, and it does not guarantee they are internals-free. Confirm with a code read.
• No security or behavioral content in this release. 1.5.0 is one compatibility line plus four cosmetic/bot changes. There is no new capability to adopt and no CVE path demonstrated — the release shows maintenance activity, not a security-response process.
• Framework coupling risk is reduced but not eliminated. A future Laravel 14 remains an unhedged exposure under a single maintainer, and the historical absence of dependents means the code is still lightly exercised by third parties.
• Supply-chain risk remains low: MIT, small surface, easy to audit.

Key questions

1. Is the repository genuinely active on Packagist/GitHub now, or was the archived flag accurate and this release represents a final unarchive-then-rearchive? Verify before changing any dependency policy.
2. What is the exact macro inventory, and which macros do we actually need? (Still likely a small subset.)
3. Do the macros use only public PendingRequest/Response API? The L13 release is evidence, not confirmation.
4. What are the new declared PHP and Laravel bounds, and is the L13 bump additive (widened range) or a floor raise that drops older Laravel versions we still run?
5. Does the L13 compatibility work ship with test coverage against L13, or was it a constraint-only change?
6. Are there macros registered under generic names likely to collide with ours?
7. Is there a stated succession or contribution path for a single-maintainer project we are considering depending on?

Integration Approach

Stack fit

• Unchanged: Laravel + Guzzle, PHP 8.x, zero infrastructure, no queue/worker/cache implications. A pure code-level convenience layer, cheap to adopt or drop.

Migration path — revised recommendation: the dependency is now defensible; the decision is conditional, not automatic

• The prior recommendation (vendor the patterns, decline the dependency) was driven by archived status. That driver is gone. Taking the dependency is now a legitimate option and should be evaluated on merit rather than reflexively rejected.
• Adopt the dependency when the macro inventory maps cleanly onto conventions we would otherwise hand-roll across several services, and we are on or moving to Laravel 13. Pin the constraint, add a composer audit gate, and record an exit ticket (owner + review date) at merge — the exit criterion is "upstream dormant >12 months" or "a Laravel major ships without a corresponding compatibility release."
• Still vendor the patterns when we need only two or three macros. At that size, ~50 lines of owned, tested code in an application service provider remains cheaper than a dependency, and MIT licensing makes copying with attribution clean. This is now a cost judgment, not a risk mandate.
• Where the decision is close, prefer adoption for the constraint-tracking benefit (someone else watches Laravel majors) and vendoring for the ownership benefit (no one else can break us). Do not do both for the same macro.

Compatibility

• Re-check the require block: confirm the L13 change widened rather than narrowed the range, and that our current Laravel version is still inside it. A floor raise would strand any service not yet upgraded.
• Re-run the macro-name collision check against existing Http::macro / PendingRequest::macro calls in our codebase and in other installed packages. This risk is unchanged by the release.

Sequencing

1. Correct the archived flag in our inventory and confirm live maintenance status on Packagist/GitHub.
2. Enumerate macros and map each to a current pain point; drop the rest.
3. Verify public-API-only usage via a short code read (an hour, not a spike) — specifically confirm the L13 work was not a constraint-only edit.
4. Prototype in one service provider behind a feature branch, or vendor the subset directly.
5. Lock behavior with contract tests asserting request/response shape — these are what protect us across the next Laravel major, whichever path we take.
6. Migrate call sites incrementally; if the dependency was added, keep the removal ticket open with an owner and date.

Operational Impact

Maintenance

• Upstream is maintained, not abandoned — a meaningful improvement in position. Ongoing cost to us is low: macros are small and change rarely.
• Recurring cost remains the upgrade tax at each Laravel major, now demonstrably being paid upstream rather than by us. That is the primary operational argument for adopting the dependency.
• Residual concern: maintenance is one person's attention. Continuity depends on that individual, not on a team or an organization.

Support

• No formal support contract or published security process, but an active maintainer and a working issue path are now available — strictly better than the prior "no escalation path" position.
• Bus factor 1 must still be stated explicitly to whoever accepts the risk. The mitigation is our own contract tests plus a documented fork/vendor fallback, not upstream responsiveness.

Scaling

• Negligible runtime impact, unchanged. Not a throughput or memory consideration at any realistic volume.
• Organizational scaling concern stands: global macro registration means the more packages and teams touching Http, the higher the collision probability.

Failure modes

• Upstream goes dormant again: the dominant new risk. Mitigation is the exit criterion and a dated review; detect via missed Laravel major compatibility rather than waiting for a failure.
• Silent collision: another package or app provider registers the same macro name; behavior changes with no error and no log line. Unchanged.
• Upgrade breakage: a Laravel major changes an internal a macro relied on — fatal error at first outbound request, often in production if untested. Reduced likelihood after L13, not eliminated.
• Behavioral drift masked: a macro altering retry counts, timeouts, or headers changes integration semantics quietly. Unchanged.
• Constraint deadlock: the archived-package scenario is withdrawn for L13; it could recur if maintenance lapses at a future major, which is what the exit criterion guards against.

Ramp-up

• Developer ramp-up remains trivial — Laravel engineers understand the macro pattern immediately.
• Discoverability cost is slightly reduced (recent activity, a compatibility release, a visible contributor) but documentation depth and real-world example volume are still thin at 11 stars. Each macro's semantics must be established by reading source and writing a test. Budget roughly a day for audit, selection, integration-or-vendoring, and tests.