Psr7 Pack Laravel Package

Product Decisions This Supports

• Standardization / build-vs-buy: symfony/psr7-pack is a Symfony Flex metapackage — zero runtime code. It exists to answer one decision: “which PSR-7 message implementation and PSR-17 factories do we standardize on?” Adopting it means the answer is “whatever Symfony’s supported set is,” instead of a bespoke choice debated per project. You are deliberately not building or hand-curating an HTTP message layer.
• Feature enablement: Anything that constructs or consumes PSR-7 requests/responses in a Symfony app — PSR-15 middleware, PSR-18 HTTP clients, third-party SDKs that type-hint Psr\Http\Message\RequestInterface, webhook/API integration work — becomes a one-line install rather than a multi-package compatibility exercise.
• Roadmap signal (v1.3.0): This release changes what is in the box. The pack now depends on php-http/discovery rather than pinning nyholm/psr7. Practically, the decision shifts from “we chose Nyholm” to “discovery selects an implementation at install time, with Nyholm still the expected default.” Treat this as a supply-chain and lockfile-determinism consideration, not a feature. The relevant PM question becomes: do we accept dynamic implementation selection, or do we pin an implementation explicitly for reproducible builds?
• Operational consequence to plan for: php-http/discovery is a Composer plugin. Projects must allow it via config.allow-plugins in composer.json. This affects CI pipelines, hardened build images, and any org policy that restricts Composer plugins — a governance item, not an engineering one.

When to Consider This Package

Adopt when:

• You are on Symfony with Flex and need PSR-7 messages for a library or SDK that requires them.
• You want the supported, low-effort dependency set rather than manually pairing nyholm/psr7 with psr/http-factory.
• You are comfortable letting Composer resolve the concrete implementation (the v1.3.0 posture) and can add php-http/discovery to allow-plugins.

Re-check before upgrading to v1.3.0 when:

• CI runs composer install --no-plugins, or your organization blocks Composer plugins — this update will not behave as expected until that is resolved.
• Code relied on nyholm/psr7 being present transitively. Since the pack no longer hard-requires it, such usage must be declared explicitly or it can vanish on a future composer update.
• You already pin nyholm/psr7 directly for reproducibility — in that case the pack adds little and you can depend on the implementation yourself.

Look elsewhere when:

• You are not on Symfony Flex — just composer require nyholm/psr7 psr/http-factory and skip the indirection.
• You only need PSR-7 objects in tests (use the implementation directly; no pack needed).
• What you actually need is an HTTP client, not message objects — that is symfony/http-client or a PSR-18 client, a different decision entirely.
• Your environment mandates a fixed, auditable dependency graph with no Composer plugins.

How to Pitch It (Stakeholders)

For executives: This is a free, code-free convenience dependency that keeps us on Symfony’s supported path and ends the recurring “which HTTP message library?” debate in every new service. v1.3.0 is a maintenance release — no new capabilities, no cost, no user-visible change. The only action item is a small build-configuration check if our CI restricts Composer plugins.

For engineering: Patch-level release, but it is a dependency-graph change, not a no-op. The pack now pulls php-http/discovery instead of nyholm/psr7, which means (a) allow-plugins must permit the discovery plugin in composer.json, and (b) any code relying on nyholm/psr7 arriving transitively must now declare it directly. Recommended: pin the implementation explicitly if reproducibility matters more than convenience, and review the lockfile diff as part of the upgrade rather than treating this as a routine bump. Low risk, but it should be a deliberate upgrade, not an auto-merge.