Request Input Bundle Laravel Package

Technical Evaluation

Architecture fit

• sfmok/request-input-bundle is a Symfony bundle, not a Laravel package. It is wired through Symfony's Bundle / Flex recipe mechanism, so it does not fit a Laravel-first stack without an adapter layer. Treat the "Laravel/PHP package" framing as inaccurate: the realistic consumers are Symfony applications (or PHP services that already boot the Symfony HttpKernel).
• If our stack is Laravel-heavy, architectural fit is low to moderate — the request-input mapping behaviour can be reproduced with Laravel FormRequests or a small custom middleware, so the dependency would add surface area without proportionate value.

Integration feasibility

• Composer install is trivial; the practical constraint is the version matrix, which v2.0.0 changed.
• A major version bump (v1.2.6 → v2.0.0) driven solely by "Support Symfony 8" is the material signal. Symfony 8 implies a PHP floor of 8.4, which will exclude a large share of our current runtime fleet.
• The changelog exposes only one line for a major release. We cannot confirm from release notes whether Symfony ≤7 support was dropped, whether PHP constraints moved, or whether unrelated BC breaks rode along in the same tag.

Technical risk

• Opacity risk (high): a major bump with a one-line changelog means we must read composer.json and the PR diff before trusting any upgrade.
• Bus-factor risk (high): single maintainer (@sfmok), small release cadence, no visible LTS or security-patch commitment.
• Constraint-drift risk (medium): if v2 drops Symfony 6/7, projects pinned to older LTS lines lose security patching the moment upstream stops backporting.
• Scope risk (low): the package is narrow in purpose, so blast radius if it breaks is contained.

Key questions

1. What are the exact php and symfony/* constraints in v2.0.0's composer.json, and is v1.2.x still maintained for security fixes?
2. Does v2.0.0 drop Symfony 6.4/7.x support outright, or add Symfony 8 additively?
3. Are there BC breaks beyond the Symfony 8 addition? The changelog does not say.
4. Is there a Laravel-native equivalent already in our dependency set that makes this package redundant?
5. What is the maintainer's stated support window, and is there a second contributor?

Integration Approach

Stack fit

• Symfony 8 projects: direct fit, upgrade path is a standard minor-style composer bump despite the major tag.
• Symfony 6.4 / 7.x projects: stay on ^1.2 until the framework upgrade lands; do not force v2.0.0 in.
• Laravel projects: do not integrate. No Bundle registration path exists in a standard Laravel bootstrap; the cost/benefit does not clear the bar.

Migration path

1. Audit composer.json and composer.lock across all services for current sfmok/request-input-bundle constraints and pinned Symfony/PHP versions.
2. Read the v1.2.6…v2.0.0 diff and the v2.0.0 composer.json to enumerate actual BC breaks (do not rely on the changelog).
3. Classify services into three buckets: (a) already on Symfony 8 → adopt v2, (b) on Symfony 6.4/7.x → hold at ^1.2, (c) Laravel → remove or never add.
4. For bucket (a), run the upgrade behind the existing test suite in a branch; the package's behavioural surface is small, so a green suite is strong evidence.

Compatibility

• Blocking constraint is the PHP floor implied by Symfony 8. Confirm our CI matrix covers PHP 8.4 before scheduling any v2 rollout.
• Check for transitive conflicts: a ^2.0 constraint may force Symfony 8 across the whole dependency graph via Composer's solver, silently upgrading unrelated packages.

Sequencing

1. Pin every service explicitly to ^1.2 today to prevent an accidental resolver-driven jump to v2.0.0 on the next composer update.
2. Complete the diff review and constraint documentation (1 sprint).
3. Pilot v2.0.0 on the lowest-risk Symfony 8 service.
4. Roll out per-service only after the corresponding Symfony 8 migration, not before.

Operational Impact

Maintenance

• Low ongoing maintenance burden: the package is small and stable, and the release cadence is slow.
• The absence of a detailed changelog for a major release means we should budget recurring effort to diff upstream ourselves rather than trusting release notes.

Support

• No published support policy, LTS commitment, or security disclosure process visible. For a package in the request-handling path, that is a real gap — request input mapping touches user-supplied data.
• Mitigation: fork-and-vendor if the package becomes load-bearing, or replace with in-house middleware where the behaviour is simple enough.

Scaling

• Negligible runtime scaling concern; the bundle operates per-request with trivial overhead.
• Organisational scaling is the issue: a single-maintainer dependency in many services multiplies upgrade coordination cost at each Symfony major.

Failure modes

• Silent major adoption: an unconstrained composer update pulls v2.0.0 and forces a Symfony/PHP bump, breaking builds. Highest-probability failure; mitigated by explicit ^1.2 pins.
• Abandonment: maintainer goes inactive and no Symfony 9 support arrives. Mitigated by vendoring or in-house replacement.
• Constraint cascade: v2's Symfony 8 requirement propagates to unrelated packages, producing a large, hard-to-bisect upgrade.
• Misdiagnosis as Laravel-compatible: a team attempts Laravel integration, loses time, and ships a bespoke adapter that recreates the package's behaviour anyway.

Ramp-up

• Engineer ramp-up is low — the package's API is small and Symfony bundle conventions are well understood by anyone on a Symfony team.
• Laravel-only engineers face a non-trivial conceptual gap (bundles vs. service providers); do not assign this integration to a Laravel-only engineer without Symfony support.
• Recommended: one engineer owns the diff review and documents the version matrix before any team-wide rollout.