Http Constants Laravel Package

Technical Evaluation

lmc/http-constants is a constants-only Composer package. It ships two flat classes — Lmc\HttpConstants\Header (header field names such as CONTENT_TYPE, AUTHORIZATION, X_FORWARDED_FOR) and Lmc\HttpConstants\Method (HTTP verbs) — with PSR-4 autoloading and no service provider, facade, config, or runtime behavior. In dependency-graph terms it is a leaf node: pure vocabulary, resolved at autoload time, with no I/O and no bootstrapping. (Note: the marketing description claims HTTP status codes; the actual source and the engineering assessment confirm it is header fields and methods. Status-code constants are not the deliverable — validate this before scoping.)

Architecture fit. Strong in principle. Because the package imposes nothing on the container or kernel, it composes with every layer of a Laravel application rather than competing with one: outbound Http::withHeaders([...]) calls, middleware that reads or writes Authorization/Accept/Cache-Control, request-inspection helpers resolving X-Forwarded-For, custom router or webhook receivers dispatching on Method::POST, and test assertions. There is no architectural coupling to unwind later.

Integration feasibility. Trivial — one composer require and import statements. No migration, registration, publishing, or configuration. The real feasibility question is not "can we" but "should we prefer this over string literals, a native PHP 8.1 backed enum, or constants we already inherit from Symfony's ResponseHeaderBag and Guzzle's RequestOptions."

Technical risk. Low at the code level, moderate at the supply-chain level. With 25 stars and zero dependents, there is no ecosystem validation and a thin maintenance surface. Abandonment is plausible but cheap to remediate: the surface area is inert constants, so a fork or inline into App\Support\Http is hours-scale, contained work. The more meaningful risks are (a) the declared PHP constraint drifting behind our runtime floor, and (b) incomplete header coverage, which invites a mixed constants-plus-literals convention — the worst of both worlds.

Key questions.

• What PHP version range does the current release declare, and does it match our Laravel runtime matrix?
• Does the constant set cover the headers we actually send — vendor X- headers, Prefer, conditional-request headers, Idempotency-Key?
• Is naming aligned with Symfony/Guzzle/PSR-7 conventions, so developers don't context-switch between vocabularies?
• Last commit date and release cadence — and is there an obvious successor if it stalls?
• Are constant names stable and documented well enough for PHPStan/Psalm custom rules to enforce usage?
• Would a scoped in-house backed enum give stricter typing with zero third-party exposure?

Integration Approach

Stack fit. Good but optional. Laravel/Symfony already expose overlapping header constants, and Guzzle carries its own. The decision is whether this package becomes the canonical header vocabulary or merely one option. Canonical status is only worth it if usage is consistent across clients, middleware, controllers, and tests — a half-adopted constants package is strictly worse than disciplined string literals.

Migration path. Purely additive and reversible. Start with new code: outbound Http::withHeaders calls, security/CORS/cache-header middleware, and request-inspection helpers. Then sweep existing literals opportunistically as files are touched, driven by static analysis rather than a big-bang refactor. Each change is text-for-text and behaviorally identical, so it rides along with normal feature work and needs no release train.

Compatibility. Framework-neutral; no expected conflict with Laravel, Symfony, or Guzzle header handling. The compatibility surface to verify is the PHP constraint against our runtime matrix — if it lags, pin or fork rather than block adoption. Confirm the package does not shadow constants we already get for free; two sources of truth is a net negative.

Sequencing.

1. Spike (half a day): validate PHP constraint, survey actual header usage against the constant list, check static-analysis behavior.
2. Coding standard: document that new code uses constants, and add a review rule or PHPStan/Psalm check if enforcement matters.
3. Pilot: apply in one or two HTTP-heavy modules — highest-density usage first.
4. Gradual sweep: replace literals in touched files during routine work.
5. Exit clause: record the fork/inline contingency in the dependency register so the low-star reality is a documented non-event rather than a future surprise.

Operational Impact

Maintenance. Near-zero runtime maintenance — no update is required for the package to keep working, and pinning insulates us from churn. The genuine cost is conceptual: a second header vocabulary alongside Symfony's and raw strings, which is developer discipline, not infrastructure. Budget modest ongoing review attention to prevent convention drift.

Support. Community-only. No SLA, no vendor backing, thin issue history. Acceptable precisely because the artifact is stateless and self-contained — a stalled tracker does not become a production incident. Keep a one-line escape hatch recorded rather than treating it as a critical-path dependency.

Scaling. No runtime scaling concerns; constants cost nothing in memory, CPU, or network. Organizational scaling is the real axis: as headcount grows, a mixed header convention is harder to normalize, so codifying the rule early is far cheaper than retrofitting it.

Failure modes. (1) Abandonment — mitigated by fork/inline. (2) Coverage gaps — mitigated by a documented fallback rule or a local extension class. (3) Convention drift — mitigated by static analysis or review rules. (4) PHP incompatibility after a runtime upgrade — mitigated by pinning or forking. None are availability failures; blast radius is developer ergonomics.

Ramp-up. Immediate. Header::CONTENT_TYPE needs no explanation, no onboarding doc, no architecture context — five minutes and an engineer is productive. The inverse holds too: the package teaches nothing and abstracts nothing, so it saves little ramp-up and has a low value ceiling.

Bottom line. A low-cost, low-ceiling, easily reversed dependency. Reasonable to adopt for teams that want a standardized header vocabulary and will enforce it; not worth adopting if it will coexist with literals and framework constants. Recommend a time-boxed spike against real header usage, adoption only under an explicit coding convention, and a recorded one-line exit strategy — folded into an existing HTTP-client refactor or tech-debt sprint rather than sized as its own initiative.