- How do I install lmc/http-constants in a Laravel application?
- Install it with Composer using composer require lmc/http-constants. There is no service provider, facade, config file, or publish step to run. After installation, import Lmc\HttpConstants\Header or Lmc\HttpConstants\Method where you need them. Composer autoloading handles the rest.
- Which Laravel versions support lmc/http-constants?
- The package is framework-agnostic, so Laravel support is mainly determined by its declared PHP version constraint rather than a Laravel version constraint. Check the composer.json PHP requirement in the release you plan to use and compare it with your Laravel runtime matrix. If the constraint lags behind your PHP floor, pin a compatible release or fork the constants. There is no Laravel-specific bootstrapping to conflict with any version.
- Does lmc/http-constants provide HTTP status code constants?
- The package's core deliverable is HTTP header name and method constants, such as Header::CONTENT_TYPE and Method::POST. Some marketing descriptions also mention status codes, but the technical assessment says status-code constants are not actually shipped, so verify the current source before relying on them. If you need status-code constants, check the release or keep using your existing Symfony, Guzzle, or in-house constants.
- Can I use lmc/http-constants outside Laravel in plain PHP?
- Yes. It is a Composer package with PSR-4 autoloading and no framework coupling. You can import the Header and Method classes in any PHP project. No Laravel container or kernel is required.
- Do I need to register a service provider for lmc/http-constants?
- No. lmc/http-constants ships constants-only classes and has no service provider, facade, configuration, or runtime behavior. You only need Composer autoloading. That also means there is nothing to publish or configure after installation.
- How do I use lmc/http-constants with Laravel's Http::withHeaders?
- Import Lmc\HttpConstants\Header and use its constants as array keys, for example Http::withHeaders([Header::ACCEPT => 'application/json']). The header values remain ordinary strings. This replaces magic header-name strings with readable identifiers. Apply the same approach in middleware, request-inspection helpers, and tests.
- Is lmc/http-constants better than Symfony or Guzzle header constants or PHP enums?
- It is a lightweight vocabulary layer, not a replacement for every option. Symfony's ResponseHeaderBag and Guzzle's RequestOptions already expose some header constants, while PHP 8.1 backed enums can give stricter typing for in-house use. lmc/http-constants is most useful if you want one small, framework-neutral set of Header and Method names across clients, middleware, controllers, and tests. Avoid mixing multiple vocabularies in the same codebase because that is worse than disciplined string literals.
- What should I check before using lmc/http-constants in production?
- Verify the declared PHP version range against your runtime matrix and confirm the constant set covers the headers you actually send, including vendor X- headers, Prefer, conditional-reguest headers, and Idempotency-Key. The code-level risk is low because the package is inert constants, but supply-chain risk is moderate given its small ecosystem footprint. Pin the version and be ready to fork or inline the constants into App\Support\Http if maintenance stalls.
- How do I test code that uses lmc/http-constants?
- There are no special test helpers because the package only provides constants. Use the constants in your test assertions and HTTP fakes just as you would in application code. For example, assert against Header::AUTHORIZATION or Method::POST rather than repeating string literals. Static analysis rules can help enforce consistent usage if you make the package your canonical vocabulary.
- What if lmc/http-constants is missing a header or HTTP method I need?
- The constant set is finite, so some less common headers or methods may not be covered. Do not mix constants and literals randomly; either add a project-local constant or extend the vocabulary in your own App\Support\Http class. If coverage gaps are frequent, a scoped in-house backed enum may be a better fit. Otherwise, fall back to a literal only where the package has no constant and document the exception.