Raygun Bundle Laravel Package

Product Decisions This Supports

• Error-monitoring vendor selection (Raygun vs. Sentry vs. Bugsnag/Rollbar): This package is one data point in the "what would a Raygun integration cost us?" question — and the answer, on inspection, is that a third-party Symfony2 wrapper is not the integration you would actually ship. Use it to frame the real comparison: Raygun's official PHP SDK versus Sentry's first-party Laravel package.
• Build vs. buy for observability plumbing: Since this package is a thin wrapper over the vendor's own PHP client, it clarifies that the "build" side of the decision is small (~1 day of adapter work) and the "buy" side should be a maintained SDK, not an abandoned glue layer. This materially lowers the perceived cost of writing our own error-reporter adapter behind an interface.
• Legacy Symfony portfolio decisions: If any Symfony 2.x services are still running, this bundle represents a stopgap option to get crash visibility before decommissioning — but its abandonment means adopting it is a fork-and-own commitment, which should weigh toward sunset rather than extension.
• Roadmap/stack hygiene: Confirms that catalogued "PHP packages" are not automatically Laravel-compatible, supporting a roadmap decision to standardize Laravel-native observability (Sentry, Flare, Bugsnag) and explicitly exclude Symfony2-era bundles from new work.
• Incident-response readiness: Supports funding some error monitoring before a legacy system is retired, even if it means a short-lived in-house wiring rather than a package adoption.

When to Consider This Package

Consider it only if all of the following are true:

• You are maintaining a Symfony 2.x application (this is a Symfony2 bundle — it is not a Laravel package and will not install cleanly into a modern Laravel app due to conflicting Symfony component constraints).
• You already have a paid Raygun account and want the bundle-style auto-configuration the listener provides.
• The system is in maintenance mode, with a known decommission horizon, not active feature development.
• You accept that you are adopting a zero-star, zero-dependent, unmaintained package and will vendor/fork and patch it yourselves.

Look elsewhere (strongly preferred) when:

• You are building or running a Laravel application — use Raygun's official raygun4php SDK behind a small service provider, or a maintained Laravel-native package.
• You are on Symfony 4/5/6/7 — the bundle's service wiring targets an end-of-life framework.
• You require active maintenance, security patching, or vendor support, or your procurement/SCA process requires a supported integration.
• You have not yet selected an error-tracking vendor — evaluate Sentry (Laravel-native) and Bugsnag first; choosing either removes this integration problem entirely.
• Your exceptions may contain PII and you need a documented data-handling story — an abandoned integration handling exception payloads is a compliance risk.

How to Pitch It (Stakeholders)

To executives / leadership: This package was catalogued as a Laravel/PHP option, but it is actually a third-party Symfony 2 integration for Raygun error tracking — and an effectively abandoned one (zero stars, zero dependents, no maintenance). Recommendation: do not adopt it as a strategic dependency. If we want Raygun, budget for the vendor's official SDK; if we want lowest-risk error monitoring on Laravel, Sentry's first-party package is maintained and supported. The only defensible use is a short-lived stopgap on a legacy Symfony 2 system we already pay Raygun for, and even then it is fork-and-own code. Net cost of the recommended path is roughly one engineer-day plus a short review cycle — small, predictable, and it avoids an open-ended maintenance liability.

To engineering: Treat this repo as prior art, not a dependency. The framework mismatch is disqualifying for Laravel (bundle conventions vs. service providers; symfony/framework-bundle ~2.x conflicts with the Symfony components Laravel ships). If we need crash reporting, the durable design is a thin in-house ErrorReporter adapter over raygun4php: one singleton binding, one call in the exception handler's report() path (or an event listener), plus a Monolog handler for non-exception errors — and not both, to avoid duplicate reports. Put it behind an interface so the vendor is swappable, send asynchronously (queue) with sampling, timeouts, and a circuit breaker so reporting never fails or slows the request, tag reports with release and environment, and add a synthetic health-check event so a misconfigured key or backed-up queue doesn't leave us believing we have observability when we have none. Sequence it as a 1–2 day POC in staging, a canary in production, and a signal-quality and cost review at 30 days, then decide whether to keep the in-house adapter or migrate to an official package. Do not introduce this bundle into any new service boundary or any system with a multi-year lifespan.