Http Constants Laravel Package

Product Decisions This Supports

• Feature & integration work: any surface with hand-typed header names — OAuth/token flows, webhooks, payment and messaging gateway clients, CORS/security middleware — becomes a candidate for a "no magic strings" standard. The decision is whether to enforce constants in new code and refactors, not whether to "add a feature."
• Roadmap placement: this is not an epic. It belongs inside an existing HTTP-client refactor or tech-debt sprint as a low-risk, low-effort quality item. Sizing it standalone overstates its value; folding it into current HTTP work captures nearly all the benefit at near-zero cost.
• Build vs. buy: adopt (buy) is the default because the artifact is inert, MIT-licensed constants with no runtime footprint. The real decision is centralize on a shared package vs. define a scoped in-house enum — centralization only pays off if multiple teams/services need the same vocabulary and will actually enforce it.
• Use cases: published SDKs and client libraries (keeps magic strings out of public examples), multi-service PHP estates needing consistent spelling, Laravel apps wanting greppable/IDE-completable header names across Http::withHeaders, middleware, and tests, and codebases with static-analysis gates where constants let PHPStan/Psalm catch misspelled headers.
• Dependency governance: forces an explicit answer to "what is our threshold for adding a dependency?" — 25 stars and 0 dependents sits below most default policies, so decide by category (commodity utility: allow, with a documented vendoring plan) rather than case-by-case.
• Convention standardization: the meaningful PM lever is an explicit coding standard ("header names in new code use constants"), optionally backed by a lint/review rule, so a mixed constants-plus-raw-strings convention doesn't quietly undermine the investment.

When to Consider This Package

Consider it when:

• Raw header strings are repeated across controllers, middleware, HTTP clients, and tests with no existing convention.
• The team runs static analysis and values autocomplete and typo prevention across request-building code.
• You want a framework-agnostic option that works with Guzzle, PSR-7/PSR-18 clients, Laravel's Http client, and cURL wrappers alike.
• You are publishing a package or SDK and want a clean, example-friendly header vocabulary.
• You need a vendorable artifact: if it is abandoned, the constants can be copied into the codebase in minutes, so lock-in risk is near zero — record that one-line exit strategy in the dependency register.

Look elsewhere when:

• You already standardize on framework-provided constants (Symfony ResponseHeaderBag, Guzzle RequestOptions, PSR-7 implementations' own constants) — two sources of truth is worse than one imperfect one.
• Your dependency policy requires meaningful community validation (downloads, dependents, release cadence); 0 dependents will fail that bar.
• You need header values (MIME types, cache directives, auth schemes), HTTP/2 pseudo-headers, or vendor-specific headers outside the curated list.
• You are on PHP 8.1+ and would rather own a small backed enum scoped to your actual needs — fewer moving parts, no third-party exposure, stricter type safety.
• The package's PHP version constraint lags your Laravel runtime floor (verify before committing; pin or fork if it drifts rather than block adoption).
• You require active maintenance guarantees or a security-response SLA as a matter of policy, even where the risk is negligible for inert constants.

How to Pitch It (Stakeholders)

To executives: A one-file, zero-runtime, MIT-licensed utility that replaces hand-typed HTTP header strings (Authorization, Content-Type) with named constants. Cost is effectively nil; the return is a small but durable reduction in a recurring class of production bugs plus a modest onboarding speedup. Recommend folding it into an existing HTTP workstream rather than funding it as its own initiative, and be transparent about the tradeoff: 25 stars and 0 dependents means weak external validation, which is acceptable here only because the code is trivially vendorable and carries no runtime, availability, or scaling risk. The realistic failure modes are all developer-ergonomics (abandonment, coverage gaps, convention drift) with contained, hours-scale remediation — not production incidents.

To engineering: Constants give IDE completion, grep-ability, and static-analysis coverage, eliminating a typo class from request-building code across Laravel's Http client, middleware, and tests. It is framework-agnostic, so it fits Guzzle/PSR-18/Laravel without lock-in and integrates in a single composer require — no provider, config, or migration. Three things to agree on up front: (1) confirm it does not duplicate constants you already get from Symfony/Guzzle/PSR-7, since a second vocabulary is worse than one imperfect one; (2) pilot it in one or two header-heavy modules first and sweep literals opportunistically rather than big-bang refactoring; (3) pin the version with a stated willingness to vendor or fork, since upstream activity is minimal and the fork cost is minutes. The recommendation is a half-day spike validating PHP constraints and real header coverage, then adoption only under an explicit coding convention with a recorded exit clause.