Laravel Safe Request Laravel Package

Product Decisions This Supports

• Input-safety standard (engineering hygiene): The package exists to make the validated payload the default read path on FormRequest objects, so controllers and services can't accidentally reach for raw, unvalidated request data. As a PM, this is not a feature decision — it's a risk-reduction decision you can point to when asked "how do we prevent validation bypasses and mass-assignment bugs?"
• Build vs. buy vs. copy: At ~13 stars, zero dependents, and a very thin release history, this is still not a "buy" in any meaningful sense. The core value is one trait plus a small convention. The realistic decision remains copy the pattern into your own base FormRequest (or adopt Laravel's first-party equivalent) rather than take a dependency. The 2.0.1 release does not change the sizing of that work — it's still roughly a day of engineering to own the behavior internally.
• Roadmap impact: none directly; enabler: marginal. It doesn't unlock user-facing capability. Its value is in tightening the contract between HTTP layer and domain layer — relevant if you're doing a security/compliance pass (SOC 2, pen-test remediation) or refactoring a codebase with inconsistent $request->input() usage.
• Use cases where the pattern earns its keep: endpoints with large, partially-validated payloads; codebases where multiple developers touch the same controllers; anywhere you've had a bug caused by reading a field that passed validation rules but was later mutated, or reading an unvalidated sibling field.
• Portfolio/architecture signal: dependency discipline is a review checkpoint here. Adopting a single-trait micro-package for a behavior you can express in ~20 lines is a signal worth interrogating in code review standards — not an item on a product roadmap.

When to Consider This Package

Consider the pattern (not necessarily the package) when:

• Your codebase has repeated $request->validated()['field'] calls, or mixes $request->input() with validated data in the same flow.
• You maintain a shared base FormRequest already — adding a validated-only accessor is a few lines and zero ongoing maintenance.
• You're standardizing request handling across a large team and want a guardrail that fails loudly instead of silently passing raw input.
• Updated consideration: if you are pinned to Laravel 10 and want the behavior with upstream blessing, 2.0.1 now declares Laravel 10 support, which removes the most immediate compatibility objection. It does not resolve the maintainer-concentration or long-term-support question.

Look elsewhere (i.e., do not adopt as a dependency) when:

• You need a maintained dependency with a support contract. The 2.0.1 release is a single compatibility bump (Laravel 10 support) from a sole maintainer, with no dependents to signal production use and no visible security-response process. For a package that sits in the request lifecycle, the bus-factor and upgrade-risk profile is still the dominant consideration, even though the "unmaintained since Jan 2023" characterization should now be softened to "low-activity, responsive to framework upgrades."
• You're on a modern Laravel. First-party support for validated-only access has landed upstream; reaching for a third-party trait duplicates framework behavior you already get and already get maintained.
• Your team is small or your validation is trivial. The cognitive overhead of a magic accessor that silently changes what $request->foo means is a real cost; explicit validated() is clearer and self-documenting.
• You need anything beyond simple getters — nested/array access semantics, file uploads, partial validation, or sometimes rules. A one-trait package with no test/issue signal is the wrong place to discover edge cases, and a patch release adding framework support does not change that.

How to Pitch It (Stakeholders)

To executives: A small, low-risk engineering pattern, not a product investment. It prevents a class of bugs where unvalidated user input leaks into business logic — the kind of thing that shows up as a security finding in an audit. We still do not recommend taking the dependency: it's a single-maintainer micro-package with one compatibility-driven release and no production dependents. The recent 2.0.1 update (Laravel 10 support) is a mildly positive maintenance signal, but it doesn't give us a support commitment, a security-response path, or an upgrade guarantee for future Laravel versions. Instead we'll implement the equivalent in roughly a day of engineering inside our own base request class, which we control and can patch. Recommendation unchanged: steal the pattern, skip the dependency.

To engineering: The idea is sound and worth stealing — make FormRequest return validated data by default instead of raw input, so the safe path is the easy path. Release 2.0.1 is a patch that adds Laravel 10 support only: no new API, no breaking changes, no deprecations, no security-relevant changes. It narrows the compatibility gap but doesn't change the architecture call — the package is a single trait, largely superseded by first-party validated-input access in current Laravel. Recommendation stands: don't add the dependency; fold the behavior into our base FormRequest (or a small SafeRequest concern) with tests, and pair it with a lint/PR rule banning $request->input() in controllers that already have a FormRequest. If we do end up vendoring the trait rather than reimplementing it, note the MIT license and the single-maintainer bus factor in the PR description. Net cost: low. Net benefit: fewer validation-bypass defects and a clearer HTTP-to-domain contract.