Laravel Log Viewer Laravel Package

Getting Started

• Install with composer require melihovv/laravel-log-viewer. Confirm the service provider is auto-discovered in composer.json; on older Laravel versions you may need to add it to config/app.php manually.
• After install, run php artisan route:list | grep -i log to find the actual route the package registers (commonly something like /logs). Open it in a browser while running locally.
• If the package ships config/views, publish them: php artisan vendor:publish --provider="Melihovv\LaravelLogViewer\LogViewerServiceProvider" (inspect vendor/melihovv/laravel-log-viewer/src for the exact provider and config keys before assuming names).
• Where to look first: vendor/melihovv/laravel-log-viewer/src (routes, controller, reader/parser class, config) and the README. With only 10 stars and a 2020 release, the source is the documentation.
• First use case: trigger a failing request or queued job, then open the viewer to scan storage/logs/laravel.log, filter to ERROR, and copy the stack trace. It replaces tail -f when you want level filtering and file switching in a browser.

Implementation Patterns

• Local/staging triage loop: reproduce the bug → open the viewer → filter by level/file → copy trace → fix. Keep it in your local workflow rather than as an operational dashboard.
• Guard the route explicitly. Register the package routes behind web + auth, and gate by environment (e.g. only register/bind the viewer when app()->environment(['local','staging'])). Never let it be reachable unauthenticated in production.
• Custom route/config: change the route prefix or log path in the published config to avoid collisions and to point at non-default channels (e.g. a separate storage/logs/services.log).
• Programmatic use: the underlying reader/parser class can be resolved from the container (e.g. in php artisan tinker or a small Artisan command) to tail or grep logs headlessly. Verify the class name in src first — the API surface is thin and version-specific.
• Pair with channel config: keep machine-facing alerting on Log::channel(...); use the viewer only for human inspection of the same files.
• Multi-file workflow: configure the viewer with several log paths (app, queue, scheduler) so you can switch contexts without SSHing into the box.

Gotchas and Tips

• Stale package (last release 2020, low activity): verify compatibility with your Laravel version before committing. Test composer require in a throwaway branch; older packages often lean on facades/contracts or Blade syntax that later Laravel releases changed. Budget for maintaining a fork.
• Security is the main risk. Log files routinely contain tokens, PII, SQL, and request bodies. Unauthenticated access is a data leak. Add middleware and an environment check, and consider an IP allowlist on staging.
• Performance on large logs. Parsers often load the whole file or a fixed tail. With daily logs and verbose output this can be slow or memory-heavy. Rotate aggressively (daily), lower LOG_LEVEL in non-local environments, and don't assume a filtered view reflects the entire file.
• Permissions: the PHP/web user must be able to read storage/logs. Silent empty views are usually a permissions problem (chmod/chown), not a parser bug.
• Format assumptions: multi-line stack traces and JSON vs. classic single-line formats can parse inconsistently. Check the package's format/pattern config if entries look mangled or split.
• Config cache: after editing published config, run php artisan config:clear (and route:clear if you changed the route). Otherwise changes appear ignored.
• Debugging the install: php artisan route:list, composer dump-autoload, and inspection of the service provider resolve most "route not found" / "class not found" issues.
• Extension points: override the Blade view, rebind the controller/reader in a service provider, or add middleware. Given the low maintenance activity, assume you'll fork rather than upstream fixes.
• Sanity check alternatives if it lags your Laravel version: opcodesio/log-viewer and rap2hpoutre/laravel-log-viewer are more actively maintained and cover the same day-to-day use case.