Http Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy — resolved to "build" (small): iltar/http-bundle is an archived Symfony bundle (last release 2017-11-27, 39 stars, 0 dependents) that adds generic HTTP-kernel conveniences on top of Symfony. Its surface area is small and largely re-implementable in-house inside a Laravel middleware or exception handler in under a day, so the buy option carries all the cost and none of the leverage.
• Roadmap impact — none: this does not unblock, accelerate, or de-risk any roadmap item. Treat as a closed evaluation, not a candidate to schedule.
• Dependency policy / vendor-risk scorecard input: a concrete example for the "do not adopt" tier. Archived status, no dependents, and no release in ~8 years are the exact signals our intake checklist exists to catch. The 0.1575 overall / 0.1 opportunity score corroborates the qualitative read.
• Framework-fit decision: it is a Symfony bundle, not a Laravel package. Adoption in a Laravel codebase would require bridging Symfony's kernel/DI into Laravel or extracting services by hand — a port project, not an install. That asymmetry alone kills it for Laravel-first products.
• Architecture review reference: the useful output is patterns, not code. Worth a 30-minute read during design review of our own HTTP-layer helpers (problem-details/error responses, request metadata propagation, response header conventions) to sanity-check that we aren't reinventing something subtly worse.

When to Consider This Package

Consider it only in these narrow cases:

• You are maintaining a legacy Symfony 3.x application that already depends on it, and the question is "do we remove it?" rather than "do we add it?" In that case, budget the removal: vendor the handful of classes you actually use, then drop the dependency.
• You are doing historical/pattern research on Symfony HTTP-kernel ergonomics and want a worked example. Read-only; do not install.
• You need MIT-licensed prior art to crib a small helper from, with attribution.

Look elsewhere — and specifically do not adopt — when any of the following hold:

• Target stack is Laravel. Use Laravel's own Handler/Exceptions, HTTP middleware, Illuminate\Http\Client, and symfony/http-foundation (already a transitive dependency) instead. If you need Symfony-kernel behavior in Laravel, that is a signal your architecture is fighting the framework, not a package gap.
• You need maintained upstream support. No security policy, no issue triage, no PHP 8.x / Symfony 5–7 compatibility guarantees, no CI signal. Anything you depend on here becomes permanently yours to patch.
• You require a support matrix or procurement sign-off. Zero dependents means no ecosystem pressure-testing; you would be the only integration in the wild.
• Your intake bar is "released in the last 12 months, has a maintainer, has tests." This fails all three. Substitute: symfony/http-kernel + symfony/http-foundation for primitives, or a maintained Spatie/Laravel-first package for the specific behavior you actually need — and confirm the exact behavior first, because the bundle's stated scope ("adding extra functionality to Symfony") is a grab-bag, not a capability.

How to Pitch It (Stakeholders)

Executives (one paragraph): We evaluated iltar/http-bundle, a small MIT-licensed Symfony add-on, and recommend against adoption. It has been archived since 2017, has no downstream users, and receives no maintenance — meaning any bug or PHP-version break becomes our permanent responsibility. It is also built for Symfony, not Laravel, so using it in our stack would require a custom port rather than an install. The functionality it provides is narrow and inexpensive to implement ourselves if we need it at all. Recommendation: no-go; reuse as reference only. Cost avoided: an unmaintained dependency and an estimated 1–3 engineer-days of porting plus indefinite upkeep.

Engineering (short form): Do not add this as a dependency. Read it for patterns if you're designing HTTP-layer helpers, then write the ~50 lines yourself against Laravel's exception handler and middleware so the behavior stays owned, tested, and PHP-version-current. The MIT license permits pattern reuse with attribution; we do not need the code. If anyone finds this already vendored in a legacy Symfony service, flag it for removal planning rather than upgrade planning.