- Is incompass/airbrake-bundle compatible with Laravel?
- No. This is a Symfony bundle, not a Laravel package: it extends Symfony's Bundle class, registers services through a DependencyInjection extension, and hooks into the Symfony kernel. Laravel exposes entirely different extension points (ServiceProvider, the exception handler's report method, and Monolog channel drivers), so requiring it with Composer will not produce a working notifier in a Laravel app. Treat it as reference material at best, not a dependency you can install.
- How do I install and register incompass/airbrake-bundle?
- Installation is via Composer, then you register the bundle in your Symfony application's bundle list (AppKernel.php on older Symfony versions, config/bundles.php on newer ones). After registration you publish the bundle configuration and supply your Airbrake credentials. Because the repository name differs from the Composer package name, confirm you are pulling the source you actually expect before committing it to a project.
- How do I configure the Airbrake project ID, API key, and environment?
- The bundle reads its credentials from Symfony configuration, typically a project ID and API key plus an environment setting that tags each reported error. In a Symfony app that configuration lives under your bundle's config key in config/packages, with secrets supplied through parameters or environment variables. In a Laravel app there is no equivalent config path for this bundle; you would place the same values in config/services.php and .env if you wrote your own integration.
- Which PHP and Symfony versions does this bundle support?
- You must verify this yourself by reading the composer.json constraints before writing any code. Bundles of this vintage commonly rely on container patterns that were removed in Symfony 5 and 6, and may not run on current PHP 8.x without patching. Given the zero-star, zero-dependent status, assume nothing is guaranteed until you have run it on your target runtime.
- How does the bundle automatically report uncaught exceptions?
- It registers listeners against Symfony's kernel event hooks so that exceptions bubbling out of a request are forwarded to Airbrake without any code in your controllers. That wiring depends entirely on Symfony's event dispatcher and kernel lifecycle. Laravel dispatches its own events and routes exceptions through Illuminate's handler, so this integration cannot be reused as-is.
- Can I report caught exceptions manually with the notifier service?
- Yes. The bundle exposes Airbrake's notifier as a container service, so you can inject it and report exceptions you catch and handle yourself. This is the useful pattern to copy if you are building your own integration, since it keeps reporting out of application logic. In Laravel the equivalent is a small bound service or facade wrapping the vendor's PHP SDK.
- How do I keep development and test errors out of Airbrake?
- The bundle supports environment-aware reporting, so you enable it only for the environments where you want telemetry, typically production and staging. That keeps local noise and test-suite failures out of your dashboard and your alerting. For testing, point the notifier at a stub or disable reporting in your test environment, then assert on the dispatch rather than on the remote dashboard.
- Is this package actively maintained and safe to run in production?
- The signals are poor: zero stars, zero dependents, no visible release cadence, and a package name that does not match its repository, suggesting a fork or rename with unclear provenance. Adopting it means owning it, because there is no upstream to merge security fixes from. If you must use it, budget a named maintainer at roughly one to two days per quarter for dependency drift and incident response.
- What is the Laravel equivalent if I genuinely need Airbrake error tracking?
- Build a thin adapter instead of installing a Symfony bundle: bind the vendor's Airbrake PHP SDK in a dedicated service provider, call it from the report method of your exception handler, and add a Monolog handler for non-exception error logs. Keep configuration in config/services.php and .env like every other observability integration you run. That is roughly 50 to 100 lines of owned glue, which is far less risk than adopting an unmaintained fork.
- How does this compare with Sentry or Bugsnag for Laravel error monitoring?
- Sentry and Bugsnag both ship first-party Laravel SDKs that register their own service provider, hook into the exception handler, and document framework-version support, so there is no glue code to own. Unless Airbrake is contractually required, standardising on one of those retires the question entirely and removes a permanent maintenance tail. If Airbrake must stay, isolate it behind your own package and pilot it on one non-critical service before rolling out.