Livewire Strict Laravel Package

Getting Started

wire-elements/livewire-strict adds an opt-in "strict mode" to Livewire components: once enabled, any public property updated from the frontend that is not covered by a validation rule throws an exception instead of being silently mutated. It closes the gap between Livewire's convenience (public properties are writable from the browser) and the assumption most developers make (that only validated fields can change).

Minimal steps

composer require wire-elements/livewire-strict:^2.0.2

No manual provider registration is required — package discovery handles it. There is nothing to publish to get started; strict mode is enabled per component rather than globally by default.

First use case

Take an existing form component and opt it in:

use Livewire\Component;
use WireElements\LivewireStrict\Attributes\Strict;

#[Strict]
class EditPost extends Component
{
    public Post $post;
    public string $title = '';
    public string $slug = '';

    protected function rules(): array
    {
        return [
            'title' => ['required', 'string', 'max:120'],
            'slug'  => ['required', 'alpha_dash', 'max:120'],
        ];
    }
}

Then try to tamper from the browser console ($wire.set('post.id', 99)) — you'll get an exception naming the offending property. That exception naming the property is the whole value proposition: it tells you exactly which field you forgot to validate.

Where to look first

1. The README's "Usage" section for the exact opt-in mechanism (attribute vs. component property) in the version you installed.
2. Your existing components' $rules / rules() methods — this package makes any gap in them a runtime error, so the audit is the real work.
3. vendor/wire-elements/livewire-strict/src — it's a small package (a handful of files); reading the trait/hook that intercepts updates is faster than guessing at behaviour.

Implementation Patterns

Roll out incrementally, not globally. Strict mode is most valuable on components that accept user input and hold sensitive state (models, IDs, ownership flags). Enable it on new components by default, then migrate legacy ones one at a time — a global switch will surface every unvalidated property at once and turn your error tracker into a firehose.

Pair strict mode with #[Locked]. They solve different problems and belong together:

#[Strict]
class EditPost extends Component
{
    #[Locked]
    public int $postId;      // never writable, full stop

    public string $title;    // writable, but must be validated
}

#[Locked] is a hard deny; strict mode is "writable but must have a rule". Anything identifying which record you're operating on should be #[Locked], not merely validated — a required|exists:posts,id rule still lets a user retarget the component at another tenant's post if your authorization lives in mount().

Move rules out of $rules into rules(). Dynamic rule arrays (e.g. 'email' => 'unique:users,email,' . $this->userId) already need a method; strict mode makes the method the single source of truth and avoids the classic bug where a property is added to the class but not to the property-level array.

Cover nested and array properties explicitly. If a component binds wire:model="items.3.qty", strict mode needs a rule that matches that path (items.*.qty). A rule on items alone is not a substitute — verify this against your Livewire version, because nested-path matching is the single most common source of false positives during rollout.

Use it as a test gate in CI. Because the failure is an exception at update time, you can assert it:

Livewire::test(EditPost::class, ['post' => $post])
    ->set('post.id', 9999)          // uncovered/unlocked property
    ->assertStatus(500);            // or assertException(...)

A small "strictness" test per component is cheap and catches regressions when someone adds a public property six months from now.

Handle the exception deliberately in production. An uncaught strict violation is a 500. That's arguably correct (it's a developer error, not a user error, in the "forgot a rule" case) — but it's also reachable by an attacker, so decide whether you want it reported to Sentry, throttled, or converted to a 400 in bootstrap/app.php's exception handler. Don't let tampering attempts page your on-call at 3am.

Combine with wire:model.live debouncing for UX. Strict mode changes nothing about the frontend; users still get Livewire's normal validation error bag from $this->validate(). Strict mode is the server-side backstop behind it.

Gotchas and Tips

Pin ^2.0.2 if you're on Livewire 4. This release is solely a compatibility fix for running against both Livewire v3 and v4. On 2.0.1 with Livewire 4 installed you may see spurious strict violations or a hard failure in the update pipeline — the fix is in 2.0.2, so there's no reason to be on 2.0.1. Conversely, if you're on v3 and seeing strict-mode oddities, confirm you're not accidentally pinned to an older 1.x line.

Strict mode fails closed, which means it fails on things you didn't think of. File uploads (TemporaryUploadedFile properties), wire:model on computed-ish fields, and properties only mutated by updated() hooks all need rules or an exemption. Audit with a grep for public in components that have the attribute.

#[Validate] attribute rules may not satisfy strict mode. Livewire 3 introduced per-property #[Validate] attributes as an alternative to $rules. Whether the package's rule resolution understands them is version-dependent — if you use attribute-based validation and get violations on properties you know are validated, that's the first thing to check. Falling back to rules() for strict components is the safe path.

Dynamic rules evaluated lazily can miss. If rules() returns different keys based on component state (a wizard step, a $this->type switch), a property that's only validated on step 3 will throw on step 1. Either validate on every step or scope strict mode to the components where the rule set is stable.

The exception message is the debugging tool. It names the property that failed. When you see one in logs, the fix is almost always "add a rule" — but occasionally it's "this should have been #[Locked]" or "this property should be private". Treat each occurrence as a design question, not just a rule to paste in.

mount() and server-side assignment are unaffected. Strict mode guards the hydration/update path from the client, not your own code. You can still set $this->title = $post->title in mount() freely.

Extension point: the package is small enough to fork. If you need nuanced policy — per-property exemptions, logging instead of throwing in staging, integration with your authorization layer — the interception happens in one place. Reading those ~100 lines before working around them is usually faster than fighting the default behaviour.

Don't treat it as an authorization layer. Strict mode answers "is this property allowed to be written at all?" It does not answer "is this user allowed to write it?" Ownership checks still belong in mount(), authorize(), or a policy — and the #[Locked] on your identifier property is what keeps those checks meaningful.