- Does fp/badaboom-bundle support Laravel?
- No. fp/badaboom-bundle is a Symfony 2.x bundle that is registered in AppKernel.php and configured through YAML service definitions, and Laravel has no bundle concept at all. It ships no Laravel service provider, no package auto-discovery entry, and no CompilerPass or services.xml consumption that a Laravel application could use. Any description claiming Laravel support is incorrect and should not be used as a basis for evaluation.
- Can I install fp/badaboom-bundle in a Laravel 10 or 11 application?
- In practice, no. The package's Composer constraints target PHP 5.3 through 5.6 and Symfony 2.x, so dependency resolution fails on PHP 8.x and any current Laravel release. Even if you forced the install with loosened constraints, there is no Laravel integration code to boot. Treat installation success as a milestone that must be proven, not assumed.
- How do you install and register fp/badaboom-bundle?
- You require the package with Composer, register the bundle in your Symfony AppKernel's bundle list, and configure handler chains through YAML service definitions. That workflow is specific to Symfony 2.x and has no equivalent in a Laravel skeleton. There is no artisan command, config publish step, or facade to work with.
- What PHP and Symfony versions does fp/badaboom-bundle require?
- The bundle is pinned to PHP around 5.3 to 5.6 and Symfony 2.x. Those constraints will not resolve on PHP 8.x or on any modern Symfony or Laravel release. Running it at all would require a fork with Composer pins loosened, dead transitive dependencies replaced, and PHP 8 type-hint remediation done, which is unplanned work.
- What does fp/badaboom-bundle actually do?
- It wraps Formapro's BadaBoom exception-handling library and exposes it to a Symfony container. The bundle's value is the Symfony plumbing itself: dependency injection configuration, YAML handler chains, and a kernel.exception listener. The underlying library delegates exceptions to a chain of reporters, and the bundle simply wires those reporters up.
- Is fp/badaboom-bundle actively maintained?
- No. The repository has roughly two stars, zero dependents, no release cadence, and no security response process, which makes it effectively dormant. If you adopted it, you would own patching and PHP version currency in perpetuity. There is no indication that BadaBoom itself is receiving security patches.
- What are the best alternatives to fp/badaboom-bundle for Laravel error reporting?
- Use a maintained reporter instead: Sentry SDK or Flare for Laravel, with Bugsnag as another option. Laravel's native report() and render() pipeline already gives you an exception handler that can delegate to multiple reporters. Genuinely needed handler-chain behavior can be reimplemented as Laravel notification channels for mail, Slack, or webhooks.
- Is fp/badaboom-bundle safe to use in production?
- It carries high risk. A throwing handler aborts the reporter chain and can mask the original exception, which is the worst possible failure mode for an error-reporting tool. The bundle also ships a HipChat handler targeting a service that no longer exists, and the Symfony 2.x and PHP 5.x constraints mean you would be running unpatched code in production.
- How do you migrate off fp/badaboom-bundle in a legacy Symfony application?
- Freeze the package version, isolate it behind a documented exception-handling boundary, and open a migration ticket so no new usage or configuration expansion happens. Then standardize on a maintained reporter such as Sentry for Symfony and remove the bundle once the boundary is no longer needed. Porting the underlying BadaBoom library into a cross-framework adapter is possible but not recommended.
- Can I port fp/badaboom-bundle to Laravel with a service provider?
- You could technically discard the bundle, depend on the underlying bada-boom library, wrap it in a Laravel service provider, and translate the YAML handler chains into a PHP config array. That is a build project to replicate functionality that Sentry, Flare, or Bugsnag already provide with active maintenance. It is only defensible if a Symfony app cannot migrate and behavioral parity is a hard requirement.