Livewire Combined Request Laravel Package

Product Decisions This Supports

• Build vs. buy for a cross-cutting concern. The package replaces a hand-rolled base FormRequest (or trait) that most Laravel teams end up writing themselves once they have both a JSON API and a Livewire UI. The in-house equivalent is small but non-trivial (parameter resolution, auth callback plumbing, camelCase mapping, file upload handling), so this is a genuine make-or-buy call rather than a feature request.
• Single source of truth for validation and authorization. Today, rules and Gate/can checks are duplicated between controllers and Livewire components. That duplication is a recurring defect source: a rule tightened in the API drifts from the form. Adopting this package collapses two implementations into one, which directly reduces bug surface and QA matrix size.
• API-first with a Livewire front end. If the roadmap commits to exposing the same writes through both an API (Sanctum/JSON) and Livewire screens, this package makes that dual-surface strategy cheaper to sustain. It supports a deliberate architectural position: validation lives in request objects, not in components or controllers.
• Sequencing of UI/API work. Because the request class is shared, the second surface becomes mostly wiring rather than reimplementation. That lowers the marginal cost of shipping an API endpoint after a Livewire screen (or vice versa) and can de-risk splitting a monolith page into an API + thin client.
• Authorization consistency as a product requirement. The notifyAuthorizationUsing hook gives a single, controllable UX for authorization failures in Livewire contexts (toasts, flashes, dispatched events). That is a UX decision point — how permission errors present — that would otherwise be ad hoc per component.
• Incremental adoption / exit cost. Adoption is per-request-class, not per-application. This allows a pilot on one or two high-traffic forms before any broad commitment, and a clean rollback path if it does not fit.

When to Consider This Package

Adopt when:

• The stack is Laravel 10/11/12 with Livewire 3/4 and PHP 8.1+, and you already maintain both HTTP controllers and Livewire components that write to the same models.
• You are feeling concrete duplication pain — the same rules() array copy-pasted, or authorization checks re-implemented in save() methods.
• You want zero configuration: no service provider registration, no config file, drop-in base class.
• Your team is comfortable owning a thin dependency and can pin a version.
• You need the standard FormRequest hooks (prepareForValidation, withValidator, passedValidation, messages, attributes) to keep working identically in both contexts — this is a meaningful fidelity signal, not just rule sharing.

Look elsewhere or build in-house when:

• There is no Livewire in the product. Without a second surface, this package adds a dependency for zero benefit — plain FormRequest suffices.
• You require vendor-backed support, SLAs, or security review of dependencies. Signals here are weak: 1 GitHub star, 0 dependents, single maintainer. That is a real supply-chain and bus-factor consideration for anything beyond internal tooling.
• You already have a deep, customized FormRequest hierarchy. The required mixin pattern may conflict with existing base classes.
• You need more than validation sharing (e.g., a full DTO / data-mapping layer, typed input objects). This solves a narrower problem; do not stretch it.
• Compliance regimes require dependencies with sustained release cadence and community scrutiny. The package has a changelog and tagged releases, but adoption evidence is essentially absent.
• Alternatively, the internal fallback is credible: a base class plus a validateLivewire static method is on the order of a few hundred lines. If the team has spare capacity and wants full ownership, that is a defensible alternative.

How to Pitch It (Stakeholders)

For executives / leadership: We are duplicating validation and permission logic across our API and our Livewire UI, which means the same rule can be enforced in one place and forgotten in another. This package lets us define rules and authorization once and reuse them in both contexts. It is Apache-2.0, zero-configuration, and per-class adoptable, so the downside is bounded: we can pilot it on a couple of forms and remove it without rework. The main caveat is maturity — it is a very small, single-maintainer open-source project, so we should pin the version and treat an internal fork as the fallback. Net: lower defect rate and cheaper dual-surface delivery for a low, reversible dependency cost.

For engineering: A CombinedFormRequest base class that behaves like a normal Laravel FormRequest in controllers and exposes validateLivewire($component, $params) for components. It handles route model binding in HTTP and explicit parameter injection in Livewire through a unified parameter() accessor, throws descriptive exceptions on missing required parameters, and preserves all standard hooks. Optional camelCase↔snake_case conversion is off by default; an authorization-failure callback lets us centralize the error UX. Risk profile: near-zero integration cost, but we own the fork if the package stalls — so pin the version, keep request classes thin, and avoid depending on the optional conversion features until they have proven stable in our codebase.