Trap Laravel Package

Getting Started

Start by installing the package via Composer: composer require --dev buggregator/trap. Once installed, run the debug server using php artisan trap:server (Laravel) or vendor/bin/trap-server (framework-agnostic). The server starts on http://127.0.0.1:8000 by default and provides real-time visibility into logs, exceptions, SQL queries, and HTTP requests. The first use case is typically catching exceptions locally without sifting through log files—you trigger an error in your app, and it appears instantly in the web UI.

Implementation Patterns

Integrate Trap into your workflow by leveraging its middleware (for HTTP requests), event listeners (e.g., QueryExecuted, ExceptionCaught), and manual instrumentation. In Laravel, enable automatic collection by adding the Buggregator\Trap\TrapMiddleware::class to your HTTP kernel. For database debugging, the package hooks into Laravel’s query listener by default. You can also manually send data using Trap::info(), Trap::error(), or Trap::sql($query) for custom tracking. For non-Laravel projects, use Buggregator\Trap\Handler directly in your exception handler or via a PSR-3 logger bridge.

Gotchas and Tips

• Double-encoding in logs: Avoid passing arrays/objects directly to trap_log(); serialize them first (e.g., json_encode($data, JSON_PRETTY_PRINT)) to ensure readability in the UI.
• Performance: The server auto-detects environment (APP_DEBUG=true); never run it in production. For local dev, use .env.trap to keep configs isolated.
• Missing SQL data? Ensure DB::enableQueryLog() isn’t disabled in your test setup.
• Web UI won’t connect? Check port 8000 isn’t blocked and that the server is running in the foreground (or use --detach for background mode, though logs won’t stream in real-time).
• Extend it: Use the Trap::extend() method to add custom panels—great for tracking app-specific metrics (e.g., rate limits, cache misses).