- Can I use nietonfir/raygun-bundle in a Laravel application?
- No. This is a Symfony 2 bundle built around the Symfony bundle, dependency-injection extension, and configuration-tree machinery, none of which Laravel has. Laravel's container borrows Symfony components but provides no registerBundles() loader and no Resources/config/services.yml convention, so every line of the package's actual value is inert in a Laravel app. The only reusable content is the underlying mindscape/raygun4php client, which is framework-agnostic and importable on its own.
- Why does Composer refuse to install nietonfir/raygun-bundle on a modern Laravel project?
- The bundle constrains symfony/framework-bundle and symfony/http-kernel to the 2.x line, while modern Laravel pins symfony/* to 6.x. That is an unresolvable dependency conflict, so Composer errors out rather than warning. Running composer why-not on a scratch project will show the exact constraint chain. There is no override short of forking, which defeats the purpose.
- How do I add Raygun error reporting to Laravel if I still need Raygun?
- Skip the bundle and require mindscape/raygun4php directly. Bind a singleton in a service provider that reads config/raygun.php for the API key, region endpoint, enabled flag, sample rate, and ignored exception classes, then register the reporter with Laravel's exception handler via ->reportable(). If the client transport is synchronous, defer sending to terminable middleware or a queued job so reporting stays off the response path. Expect roughly 60 to 150 lines of glue.
- Is nietonfir/raygun-bundle still maintained?
- Treat it as unmaintained. It has one star, zero dependents, a single maintainer, and targets Symfony 2, which reached end of life in 2018, regardless of the last commit date. There is no security disclosure path, no CVE history to lean on, and no upgrade path. Adopting it into a production Laravel codebase carries abandonment risk with no offsetting benefit.
- What does nietonfir/raygun-bundle actually do?
- It wires the Raygun PHP provider and JavaScript plugin into a Symfony application. Concretely it ships a Bundle subclass, a DependencyInjection Extension, a Configuration tree, and event-subscriber service definitions that capture exceptions and forward them to Raygun. All of that is Symfony packaging; the error capture and transport logic lives in the third-party client it wraps. The wrapper is the deliverable, and the wrapper does not transfer to Laravel.
- Should I register a Symfony-style event subscriber for exception reporting in Laravel?
- No. Laravel's idiomatic hook is the exception handler's reportable() method, not a Symfony event subscriber registered through service definitions. For anything that must run after the response, use terminable middleware or a queued job instead. Mixing Symfony's listener conventions into Laravel adds indirection with no benefit.
- Is mindscape/raygun4php compatible with PHP 8.1 through 8.3?
- Do not assume it is. The underlying client still needs verification on PHP version support, curl versus stream transport, timeout behavior, and whether any async or batch mode exists. Pin the version you test and treat it as a dormant dependency until proven otherwise. A short compatibility spike is cheaper than discovering a fatal error in production.
- What data privacy concerns come with adopting a Raygun client?
- Error payloads routinely carry stack traces with absolute paths, request headers, cookies, query strings, and user identifiers. Adopting any Raygun client is a data-processing decision, not a library decision, so you need a signed DPA, a chosen region endpoint, defined retention, and scrubbing rules before shipping. This consideration dwarfs the code risk of the package itself.
- What are the alternatives to this bundle for Laravel error tracking?
- If Raygun is not a mandated vendor, evaluate a first-party Laravel SDK such as sentry/sentry-laravel, Flare, or Bugsnag. Run a short bake-off weighted on install path, async transport, PII scrubbing hooks, release tagging, cost at your log volume, and data region. First-party SDKs win on maintenance alone. If Raygun is mandated, use the client library plus your own Laravel glue rather than this bundle.
- How much work is it to build a first-party Raygun integration for Laravel?
- Roughly 60 to 150 lines: a config file, a singleton binding in a service provider, a reportable() hook on the exception handler, and optional queued dispatch for off-request sending. That is smaller than the effort of fighting the bundle's Symfony 2 constraints. The tradeoff is that you own the glue, so decide up front who patches it if the client needs changes.