Badaboom Bundle Laravel Package

Getting Started

The first thing a Laravel developer must accept: this is not a Laravel package. fp/badaboom-bundle is a Symfony 2.x bundle wrapping the Formapro BadaBoom library. The description.md claims "Laravel 9+ support" and "zero-config setup via package auto-discovery" — both are wrong. There is no service provider, no extra.laravel.providers entry, and none of the Symfony Bundle/Extension/CompilerPass machinery that the package depends on has any equivalent in Laravel's container. composer require fp/badaboom-bundle on a modern Laravel app will fail resolution because the transitive graph pins PHP ~5.3–5.6 and Symfony 2.x components.

So "getting started" splits into two honest paths.

Path A — you actually have a legacy Symfony 2 app that already ships this. This is the only real day-to-day usage. Minimal steps:

1. Confirm the bundle is already registered in app/AppKernel.php:

   new Fp\BadaBoomBundle\FpBadaBoomBundle(),
   

2. Enable and scope it in app/config/config.yml, keeping it quiet outside prod:

   bada_boom:
       enabled: true
   

   Put real transport config (email, Raven) in app/config/config_prod.yml only.
3. Look first at, in this order:
   • DependencyInjection/Configuration.php — the authoritative list of config keys. The README is thin; the config tree is the documentation.
   • Resources/config/*.xml — service IDs, tag names, and the bada_boom service alias you'll inject.
   • EventListener/ExceptionListener.php — the kernel.exception hook, its priority, and what response (if any) it returns.
   • DataCollector/ and the channel/chain-node classes — the two extension points you'll subclass.

First use case: catch an unhandled exception in prod and email the on-call dev with request URI, logged-in user and last N session values attached. Once that works, add a Raven channel — that replicates what most teams now just buy from Sentry.

Path B — you're on Laravel. Do not install this. Start from App\Exceptions\Handler::report() and a maintained reporter (Sentry SDK, Flare, Bugsnag), and reimplement the handler-chain semantics as notification channels if you need fan-out (mail, Slack, webhook). The rest of this assessment documents the package's mechanics so you understand what you are replacing — not so you can wire it in.

Implementation Patterns

These are the patterns the package is built around. They map 1:1 onto "what Laravel's report() plus a reporter SDK already does," which is the useful framing.

Automatic catching via the kernel listener. The bundle's whole value is that you don't call it. Register it, and every exception escaping a controller flows through collector → channel chain. This is the default and the only pattern worth shipping.

Programmatic catching. Inject the bada_boom service and call it for exceptions you handle yourself but still want reported:

public function __construct(BadaBoom $badaBoom) { $this->badaBoom = $badaBoom; }

try {
    $this->importer->run($file);
} catch (\Exception $e) {
    $this->badaBoom->catchException($e);
    // you decide whether to swallow or rethrow — the bundle does not
}

This is mandatory for queue workers, console commands and cron jobs, where the HTTP listener never fires. It is the single biggest gap in a naive install, and the direct analogue of calling report($e) manually in Laravel.

Channel chaining. The idiomatic setup is a chain node that fans out — email the on-call dev and land the payload in Raven. Verify both fire before trusting it: chain-node config errors fail silently rather than loudly.

Environment-scoped config. enabled: false (or empty channels) in config_dev.yml/config_test.yml. Prod gets email; staging gets the dummy channel so you can prove wiring without paging anyone.

Custom data collectors. When the built-in request/session/user payload isn't enough — tenant ID, feature flags, deploy SHA, correlation ID — implement the collector interface and tag the service. This is the most common customisation: stamp every report with X-Request-Id and current tenant so support can correlate with logs.

Custom chain nodes. For "also write to Monolog at critical" or "also bump a statsd counter," a small chain node beats fighting the email channel. This is also the escape hatch for rate limiting: a node that drops duplicate fingerprints before they reach the expensive transports.

Filtering noise. 404s and AccessDeniedHttpException are not errors. Configure exception-class filtering (or a guard node) so the channel doesn't drown in bot traffic — otherwise the first bad crawler day floods the on-call inbox and people start ignoring the alerts.

Gotchas and Tips

• The description is lying to you. "Laravel 9+", "auto-discovery", "PSR-compatible handlers" — none are true of the code. Treat any README claim as suspect until you've read Configuration.php.
• Composer will not resolve on PHP 8.x or current Symfony/Laravel. Treat "it installs at all" as your first milestone, not a given; expect to fork and loosen constraints.
• Zero upstream maintenance. 2 stars, 0 dependents, no release cadence, no security response, no PHP 8 roadmap. Adopting this means you inherit full ownership: patching, dependency updates, future compatibility.
• Silent handler failure. If one node in the chain throws, the chain aborts and can mask the original exception. Wrap nodes defensively and log node failures somewhere independent of the chain.
• Notification storms. Handlers are synchronous and per-exception. A bad deploy or DB outage fires one email/webhook per exception, and SMTP calls block the request path. You need deduplication, throttling and async dispatch before this is safe at any real volume.
• Dead transport targets. The HipChat handler points at a service that no longer exists; you'll get noise, not signal.
• Config errors fail quietly. Wrong chain-node wiring produces "enabled but silent." Prove each channel with a deliberately thrown exception in staging before trusting prod.
• No docs beyond the README. On-call engineers will have no external reference. Write an internal runbook, or accept that nobody will know how to debug it at 3am.
• The bundle is the part that doesn't port. If you're forced to reuse something, depend on the underlying bada-boom library and wrap it in a Laravel service provider / custom handler — the Symfony DI, YAML handler chains and kernel subscriber are exactly the pieces that don't transfer.
• Recommendation for a Laravel team: don't. Standardise on Sentry or Flare per framework, keep report()/render() as the extension point, and adopt a lightweight dependency checklist (maintained releases, real adoption, compatible framework version) so packages like this are filtered before they reach a build-vs-buy conversation.