swayok/laravel-extended-errors
Laravel Extended Errors enhances Laravel's exception and error handling with richer context, cleaner responses, and flexible customization for APIs and web apps, helping surface useful debugging details while keeping production errors structured and user-friendly.
The package is installed like any other Laravel package:
composer require swayok/laravel-extended-errors
Laravel's package auto-discovery should register the service provider. Publish whatever configuration it ships with:
php artisan vendor:publish --provider="Swayok\LaravelExtendedErrors\...ServiceProvider"
If the provider isn't auto-discovered (common with low-star packages), add it manually to bootstrap/providers.php (Laravel 11+) or config/app.php.
Where to look first, in order:
README.md — the only authoritative source for the config keys and handler class names. With 1 star and no dependents, don't assume the docs match convention.config/ after publishing — this tells you which channels are pre-wired and which Monolog handlers exist.src/ — specifically any *Handler.php and *Formatter.php classes; those are the pieces that plug into config/logging.php.First use case: richer local debugging. Run APP_DEBUG=true, throw a deliberate exception (e.g. throw new \RuntimeException('test') from php artisan tinker), and compare the rendered page against stock Ignition/Whoops. The package's selling point is "more info" — confirm it actually adds something useful for your workflow (query bindings, request context, environment snapshot) before adopting it elsewhere.
Second use case: HTML error output for logs and mail. Point a logging channel at the package's handler and confirm you get storage/logs/*.html (or an email) that renders the same rich template as your debug page.
Extending the debug page (local/staging only). Treat this exactly like Ignition: it should never run in production. Keep APP_DEBUG=false there and rely on your normal error reporting. In practice this means the debug-page half of the package is a developer-convenience feature only.
Wiring Monolog channels. The package provides a Monolog handler and formatter that produce HTML. The idiomatic integration is a custom channel in config/logging.php:
'channels' => [
'errors_html' => [
'driver' => 'monolog',
'handler' => \Swayok\LaravelExtendedErrors\...Handler::class,
'level' => 'error',
'with' => [
// keys from the package config, e.g. output path
],
],
],
Because it's a standard Monolog handler, you can compose it with Laravel's tap array or Monolog's own wrapping handlers (FingersCrossedHandler, DeduplicationHandler, BufferHandler).
HTML file logs. A daily-rotating HTML dump is genuinely useful in staging/QA where you want a shareable artifact. Point it at storage/logs/html-errors-YYYY-MM-DD.html and let Laravel's daily rotation apply.
HTML emails for production alerts. Use a stack channel that fans out to the normal file log and the HTML email handler, but throttle aggressively:
'stack' => [
'driver' => 'stack',
'channels' => ['single', 'errors_html_email'],
],
Send only ERROR+ and put a FingersCrossedHandler or a short dedupe window in front of it, otherwise a broken DB connection will mail you on every request.
Laravel 11+ vs. legacy. Handler registration now lives in bootstrap/app.php via ->withExceptions(...) rather than app/Exceptions/Handler.php. Configure the logging channels the same way regardless; just be aware the exception rendering hook (where a debug-page extension lives) is registered through the new Exceptions class.
Queued/spooled mail. HTML error emails composed synchronously block the request that already failed. If the package's handler uses Mail::send, consider subclassing it to dispatch a queued Mailable instead, or wrap it in a transport that writes to a spool file. This is the single biggest "day-to-day" improvement you can make over the stock handler.
Extension points worth knowing. Subclass the package handler, override getFormatter(), and swap in your own template (which is where you'd redact secrets, add a request ID, or link to your internal dashboard). The formatter is the natural seam — everything else is Laravel/Monolog plumbing you already control.
composer.json, and wrap usage behind a thin config layer so you can rip it out without touching every channel definition.LogRecord vs array). Verify which major version the package targets against your monolog/monolog constraint; a mismatch usually manifests as a TypeError on the first logged error, not at install time.<style> blocks; Outlook ignores flexbox. If the debug template isn't inlined you'll get a wall of unstyled text. Either inline CSS upstream or accept that it's only readable in a browser.storage/logs/html-* to backups/retention policies.APP_DEBUG is the switch for the debug-page half. Setting it to true on a reachable server is a remote-injection vector. Never enable it outside local.php artisan config:clear (or config:cache in deploy). This trips people up constantly with logging.php edits.tail as a deploy user, or vice versa, you'll get silent write failures — Monolog swallows them. Verify with an ls -la storage/logs after the first trigger.try/catch, then Log::channel('errors_html')->error(new \Exception('boom')) from tinker to isolate the handler from the framework. If no file appears, the issue is your channel config, not the package.stack channel with JSON lines give you most of this with active maintenance. The HTML email idea is nice; the implementation here is a 1-star gamble. Consider borrowing the concept (an HTML formatter on top of FingersCrossedHandler) rather than the dependency.composer.json constraints; a package this obscure almost certainly doesn't test against the newest Laravel. If you upgrade Laravel, re-run your error-path smoke test explicitly.How can I help you explore Laravel packages today?