- What does michael-rubel/laravel-helpful-traits actually do?
- It is a collection of reusable Laravel traits, and the headline behavior overrides FormRequest access so that reads like $request->key, $request->input(), $request->all(), and ArrayAccess go through $request->safe() instead. That makes unvalidated payload keys unreachable from controllers. There is no service provider, config file, or migration involved - it is a thin override layer on Illuminate\Foundation\Http\FormRequest.
- How do I install laravel-helpful-traits?
- Installing it would be composer require michael-rubel/laravel-helpful-traits, but that is not the recommended path here. The repository is archived and the last release was 2023-01-19, so you would be adopting an unmaintained dependency. Instead, vendor the roughly 30 to 50 lines of logic into an application-owned App\Http\Requests\BaseFormRequest under the MIT license with attribution and your own tests.
- Which Laravel versions does laravel-helpful-traits support?
- It targets PHP 8.x and Laravel 10 or newer, because $request->safe() and the ValidatedInput surface are what the trait depends on. It was never tested against Laravel 11 or 12, and the Request internals it monkey-patches have shifted across those majors. Verify the exact minor version exposes safe() before relying on the behavior.
- Is laravel-helpful-traits still maintained?
- No. The repository is archived, the last release was January 19, 2023, it has around 13 stars and zero dependents, and there is no maintainer path for security fixes or Laravel-version patches. Technically the security pattern it enforces is sound, but the artifact itself is not a viable long-term dependency. Treat it as reference source code rather than a Composer package.
- How does the trait prevent unvalidated input from being retrieved?
- It overrides the magic methods __get and offsetGet plus methods such as input() and all() on the FormRequest so every read delegates to $this->safe(). Any key that was not covered by your validation rules resolves to null instead of the raw payload value. That is fail-closed, which is the correct security posture, but it is debug-hostile because a missing rule looks like a silent null bug in production rather than a loud failure.
- Can I use laravel-helpful-traits with Laravel 11 or 12?
- Not officially. The package predates Laravel 11 and 12 and was never tested against them, while the Request and ValidatedInput surfaces have drifted across the 10 to 11 to 12 upgrade path. If you are on a newer major, vendor the logic into your own base request class and write tests against your installed version. Do not bundle this change with a framework upgrade.
- What are the risks of using this package in production?
- The main risks are silent nulls for keys missing a validation rule, trait collisions where another package or base class also touches offsetGet and wins by load order, and code that assumes $request->all() still contains unvalidated keys, such as query builders, API resources, and some audit loggers. The archived status compounds all of that with no route to fixes. Scope any override to FormRequest subclasses only and never replace the container Request binding, which middleware and auth depend on.
- Should I use the package or write my own BaseFormRequest?
- Write your own. A BaseFormRequest that overrides offsetGet, __get, input, all, only, and except to delegate to $this->safe(), with explicit escapes for route parameters, headers, files, and session lookups, is hours of work rather than days. You get provenance, tests against your Laravel version, and no dead dependency. The integration cost is low because nothing is installed, so there is no data model or infrastructure to migrate.
- How do I handle route parameters, headers, or uploaded files if $request->input() is restricted?
- Add explicit escape hatches in your base request class: use route() for route parameters, header() for headers, file() for uploads, and session() for session data. Those legitimately unvalidated reads must not be masked by the safe() override. Also watch for $request->merge() after validation and for FormRequest reuse inside jobs or console commands, where the HTTP assumptions no longer hold.
- What are the alternatives to laravel-helpful-traits?
- Use $request->validated() or $request->safe() explicitly in controllers and enforce it with a Larastan custom rule or a CI grep that bans $request->input() and $request->all() in controllers. That delivers most of the security value with no runtime magic and no dead dependency. Validated DTO packages such as spatie/laravel-data are another option because they make the validated surface explicit and testable.