Http Factory Laravel Package

Technical Evaluation

Architecture fit: The package provides an HTTP factory abstraction (PSR-7 message factories) consumed by HTTP clients, middleware stacks, and PSR-15 handlers. In a Laravel codebase it typically sits behind Guzzle/Symfony HTTP client configuration rather than in application domain code, so the blast radius is usually narrow and confined to the HTTP integration layer. Fit with Laravel's own request/response lifecycle is indirect — Laravel does not natively speak PSR-7, so any usage is already mediated by a bridge.

Integration feasibility: Migration to psr/http-factory is structurally low-risk. The replacement is a PSR interface package (interfaces only, no implementation), which means the consuming code must pair it with a concrete PSR-17 implementation (e.g. nyholm/psr7, guzzlehttp/psr7). The interfaces are near-identical in shape, so the work is primarily: swap the dependency, update use statements, and confirm the container bindings resolve a concrete factory.

Technical risk: The dominant risk is end-of-life, not functionality. This is the final release, so there will be no security patches, no PHP-version compatibility fixes, and no support for future PSR revisions. Secondary risk is dependency resolution drift: as other packages bump to psr/http-factory, Composer may eventually be unable to satisfy both trees, turning a quiet deprecation into a blocking build failure. Third risk is institutional — without a tracked owner, the package silently persists in composer.json for years.

Key questions:

• Which concrete PSR-17 implementation are we standardising on, and does it already exist in the dependency tree?
• How many first-party and third-party packages pin this library, directly or transitively?
• Is there a hard deadline (PHP minor upgrade, framework major) that converts this from advisory to blocking?
• Who owns the remediation ticket, and what is the target sprint?
• Are there any behavioural differences between this factory's output and the replacement's (header handling, stream defaults, URI normalisation)?

Integration Approach

Stack fit: Confirm the installed PSR-17 implementation is compatible with the Laravel and PHP versions in use. Laravel's HTTP client wraps Guzzle, which ships its own PSR-7/PSR-17 support — in most cases the concrete factory is already present and the abstraction package is redundant. Verify service provider bindings before assuming zero code change; some packages type-hint the old factory interfaces in container bindings or config files.

Migration path: Treat this as a dependency-substitution task, not a rewrite. Sequence: (1) inventory direct and transitive consumers via composer why; (2) add psr/http-factory and a concrete implementation alongside the existing package; (3) update type hints and imports in first-party code; (4) run the HTTP integration test suite; (5) remove the deprecated package; (6) confirm composer.lock diff is limited to the expected packages.

Compatibility: Watch for implementations that satisfy PSR-17 but differ in edge-case behaviour — upload factory stream handling and URI encoding are the usual divergence points. If the codebase supports multiple Laravel versions, validate the replacement across the supported matrix rather than only the newest. Third-party packages that still depend on the deprecated library will keep it in the tree; that is acceptable short-term but should be logged as a follow-up with upstream.

Sequencing: Do not bundle this with feature work. It is a small, well-bounded chore that should ship in an isolated PR behind the existing test suite, early in a sprint, so any Composer conflict surfaces with time to react. Pairs naturally with any forthcoming PHP minor upgrade, since both touch the same dependency graph.

Operational Impact

Maintenance: The package is now frozen. Every future maintenance action — PHP version bump, security advisory, PSR revision — becomes manual work or an accepted vulnerability. Carrying it is an ongoing, if small, liability with a known expiry.

Support: There is no upstream to escalate to. Internal support burden shifts entirely to the team, and the only viable remediation for any future defect is the migration we are already recommending. This should be reflected in the risk register rather than left implicit.

Scaling: Negligible performance or scaling impact — the abstraction is thin and stateless. The scaling concern is organisational: the longer the dependency persists, the more packages build on top of it and the larger the eventual migration surface becomes. Cost grows non-linearly with delay, which argues for scheduling now while the tree is shallow.

Failure modes: Three realistic failure paths. (1) Silent decay — nothing breaks, package stays for years, then blocks a PHP upgrade under time pressure. (2) Composer conflict — a dependency bumps to psr/http-factory and resolution fails, breaking CI with no warning. (3) Security advisory — no patch will be issued, forcing an emergency migration on someone else's timeline. Only the first is benign, and only until it isn't.

Ramp-up: Low. An engineer familiar with Composer and the HTTP layer can scope and execute this in well under a day, including test runs. The main cost is discovery — mapping transitive consumers — not the code change itself. Recommend a brief written migration note in the repo so the next engineer does not re-derive the rationale from the release note alone.