jeffersongoncalves / livewire-logs

2.1.0 2026-10-29 14:24 UTC

Requires

• php: ^8.2
• illuminate/contracts: ^10.0|^11.0|^12.0|^13.0
• livewire/livewire: ^4.0
• spatie/laravel-package-tools: ^1.16

Requires (Dev)

• larastan/larastan: ^3.0
• laravel/pint: ^1.24
• orchestra/testbench: ^10.0|^11.0
• pestphp/pest: ^3.0|^4.0
• pestphp/pest-plugin-laravel: ^3.0|^4.0

MIT

• Jefferson Gonçalves

• logging
• exceptions
• laravel
• logs
• livewire
• 419

Published on Packagist.org on 2026-10-29 14:25 UTC

README

Livewire Logs

When a Livewire update throws a TypeError in production, Livewire answers 419 ("This page has expired") and nothing reaches your logs: Livewire 3 never reports the error, and Livewire 4 reports it without saying which component failed.

This package makes that error show up in your logs (and in Sentry, Bugsnag, Flare...) with the component that caused it:

local.ERROR: App\Livewire\EditReadings::store(): Argument #1 ($value) must be of type int, string given
{
    "livewire": {
        "component": "edit-readings",
        "class": "App\\Livewire\\EditReadings",
        "id": "kXz3...",
        "path": "readings/42/edit",
        "step": "call: save",
        "updates": {"form.value": "string"},
        "calls": ["save"]
    },
    "exception": "[object] (TypeError(code: 0): ..."
}

The livewire context is added to every exception reported during a Livewire update, not only to TypeErrors.

Compatibility

Package	Livewire
1.x	3.x
2.x	4.x

Installation

composer require jeffersongoncalves/livewire-logs:^2.0

That's it. The user still gets the 419 response; only the logging changes. With APP_DEBUG=true the TypeError is thrown as before.

Optionally publish the config:

php artisan vendor:publish --tag="livewire-logs-config"

return [
    'enabled' => env('LIVEWIRE_LOGS_ENABLED', true),

    // Updated values may hold personal data: by default only their type is logged.
    'include_values' => env('LIVEWIRE_LOGS_INCLUDE_VALUES', false),

    'value_max_length' => 200,

    // With values on, these keys are logged as "[redacted]"...
    'sensitive_keys' => ['password', 'passwd', 'secret', 'token', 'api_key', 'private_key', 'credential', 'authorization', 'cookie', 'session', 'card_number', 'cvv', 'cvc'],
];

With include_values on, a property whose path contains a sensitive key is logged as [redacted]. Matching ignores case, _, - and ., so form.currentPassword matches password and apiToken matches token. Array values are redacted key by key, at any depth:

"updates": {
    "currentPassword": "string [redacted]",
    "form": "array {\"name\":\"Ana\",\"api_token\":\"[redacted]\"}"
}

How it works

• Livewire 4 already calls report() before abort(419); this branch only adds the component context. Livewire 4 still answers 419 without reporting when a request sets a typed public property to a value of the wrong type (it treats that as a bot probing the component); that stays as is.
• Livewire 3 (1.x) also replaces Livewire's HandleRequests mechanism with a copy whose handleUpdate() reports the error.
• Both versions listen to Livewire's hydrate, update, call and destroy hooks to remember the component being updated, and adds it to the exception context through buildContextUsing().

Testing

composer test

Changelog

Please see CHANGELOG for more information on what has changed recently.

Contributing

Please see CONTRIBUTING for details.

Security

Please review our security policy on how to report security vulnerabilities.

Credits

• Jefferson Gonçalves
• All Contributors

License

The MIT License (MIT). Please see License File for more information.