Http Laravel Package

Technical Evaluation

Architecture fit. delight-im/http is a framework-agnostic collection of HTTP primitives (status codes, methods, header handling, media/MIME types) with no Laravel service provider, no facade, and no container bindings. That makes it architecturally inert: it can be dropped into any layer without wiring, but it also means it does not participate in Laravel's lifecycle, config, or testing helpers. The critical fit question is overlap, not integration. Laravel already ships Symfony HttpFoundation (request/response/header abstractions), the Illuminate\Http\Client wrapper over Guzzle, and Symfony\Mime. Any value this package adds is therefore confined to ergonomics — named constants, small parsing helpers — rather than capability.

Integration feasibility. Composer-installable, MIT, zero transitive dependency risk in the usual sense (0 dependents is a signal of unproven, not unsafe). Integration effort is measured in hours, not sprints: composer require, then direct static calls. There is no migration surface, no schema, no runtime contract to satisfy.

Technical risk. The dominant risk is stewardship, not code. A single-maintainer repository with 18 stars, no dependents, and no visible security policy is a supply-chain and longevity concern — the code is small enough to audit and vendor, which caps blast radius, but it also means no upstream CVE response, no PHP-version guarantees, and no compatibility commitments. Secondary risks: undocumented PHP version floor, unclear PSR-7/PSR-17 alignment, and behavioural edge cases in header/URL parsing that a 20-line helper can get subtly wrong.

Key questions.

• What is the actual API surface — constants only, or stateful parsers? Constants are near-zero risk; parsing logic is where bugs live.
• PHP version support and last-commit cadence versus our Laravel/PHP baseline.
• Does it duplicate Symfony\HttpFoundation or league/uri in ways that create two sources of truth?
• Test coverage and CI status; is there a published changelog?
• Are constants aligned to IANA registries and RFC 9110, or hand-rolled?
• Maintenance posture: is the maintainer responsive, and is the license/bus-factor acceptable for a vendored fork?

Integration Approach

Stack fit. Treat this as a leaf utility, never a platform dependency. It should sit beneath application code and above nothing — no other package should depend on it. In a Laravel codebase the honest comparison set is: Symfony HttpFoundation constants, Illuminate\Http\Response status constants, Symfony\Component\HttpFoundation\Response::HTTP_*, and GuzzleHttp\RequestOptions. If the package's constants merely restate these, the fit is poor and the correct decision is no adoption.

Migration path. There is nothing to migrate — this is greenfield adoption or rejection. The realistic path is: (1) inventory the specific helper functions we would actually call; (2) verify each has a first-party equivalent; (3) adopt only the residue that has no framework equivalent, behind an internal App\Support\Http adapter; (4) forbid direct imports outside that adapter so a future swap is a one-file change.

Compatibility. Confirm the composer.json PHP constraint against our runtime matrix, check for PSR interface implementations we already depend on, and verify no function/class-name collisions with Symfony or Guzzle. Because it is dependency-free, conflict risk is low and predictable.

Sequencing.

1. Spike (1–2 days): read the source end-to-end; catalogue every public symbol.
2. Gap analysis: map each symbol to a framework-native equivalent; produce an adopt/reject list.
3. Decision gate: if the residue is under ~5 helpers, vendor the relevant code into our own support namespace rather than adding a dependency.
4. Adapter + standards entry: codify usage rules in engineering guidelines.
5. Re-evaluate annually against upstream activity.

Operational Impact

Maintenance. Low ongoing code maintenance, moderate governance maintenance. Either we pin a version and accept staleness, or we vendor the source and own it outright. For a package of this size, vendoring is the cleaner operational answer — it removes the dependency from the SBOM, eliminates supply-chain exposure, and costs roughly a day of engineering once.

Support. Community-only, MIT, no SLA, no vendor. Escalation path is "read the source." That is acceptable for a constants library and unacceptable for anything touching request parsing in a regulated or high-availability context without our own test suite around it.

Scaling. Negligible. Stateless static helpers, no I/O, no memory footprint of consequence, no per-request cost worth benchmarking. It will not be a throughput or capacity constraint at any plausible scale.

Failure modes.

• Silent incorrectness: malformed-input handling in header or MIME parsing produces wrong values rather than exceptions — the worst failure class, and the reason to insist on our own tests.
• Version drift: upstream adds a PHP 8.4 requirement or changes a constant; pinned Composer resolves it away, but security patching then stalls.
• Abandonment: repository goes dormant; mitigation is the vendor fork.
• Duplicate truth: developers use this package's constants in one place and Symfony's in another, producing inconsistent status/header values — mitigated by the adapter and a lint rule.
• Supply chain: single-maintainer account compromise; mitigated by vendoring and lockfile review.

Ramp-up. Hours for a mid-level engineer — the API is small and self-describing. The real ramp-up cost is organisational: teaching the team when to use the adapter versus framework-native primitives. Budget a short standards doc and a code-review checklist rather than training sessions.

TPM recommendation. Do not adopt as a runtime dependency. The leverage here is as a reference implementation and constants catalogue — mine it for correctness checks against our own HTTP helpers, vendor the handful of genuinely useful symbols into App\Support\Http, and keep the dependency graph clean. Score 0.21 with 0 dependents and 18 stars is consistent with that verdict: useful reading, weak foundation.