Bug Reporting Bundle Laravel Package

Getting Started

Verdict up front: do not use this package in a Laravel application. xrow/bug-reporting-bundle is a Symfony bundle, not a Laravel package. The repository description marks it as Deprecated! It has been moved. The last release was 2017-02-24, it has 0 stars and 0 dependents. There is no Laravel service provider, no package auto-discovery metadata, and no plausible compatibility path with a modern Laravel app.

Minimal steps before considering it:

1. Open the GitHub repository and read the deprecation notice. Follow the "moved" link if one exists.
2. Confirm the package type with composer show xrow/bug-reporting-bundle. It will be a symfony-bundle, not a Laravel library.
3. Check composer.json for extra.laravel.providers or extra.laravel.aliases. They will not be present.
4. Check PHP and Symfony version constraints. A 2017 Symfony bundle will typically conflict with PHP 8.x and current Laravel releases.

The first realistic use case is not integration — it is replacement. In a Laravel context, use one of these instead:

• Sentry via sentry/sentry-laravel for exception and bug reporting.
• Flare via spatie/laravel-flare or the Flare SDK.
• Bugsnag via bugsnag/bugsnag-laravel.
• Laravel Ignition / Spatie Ignition for local and production-friendly exception pages.
• A small custom bug-report endpoint if you only need an in-app "Report a bug" form.

If you inherited a Symfony application that uses this bundle, look first at the application's config/bundles.php (Symfony 4+) or app/AppKernel.php (Symfony 2/3), then at the bundle's routing and configuration files. That is where the bundle is wired in.

Implementation Patterns

Because this is a Symfony bundle, the normal usage pattern is Symfony bundle registration, not Laravel package discovery. A legacy application would typically:

1. Require the bundle with Composer.
2. Register it in the kernel or bundles.php.
3. Import its routing.
4. Configure it through Symfony configuration files.
5. Expose a bug-report form or endpoint to users.

None of that maps cleanly onto Laravel's service container, HTTP kernel, routing, or config system.

For a Laravel developer, the practical patterns are:

Pattern A — Replace with a hosted error tracker. This is the lowest-effort and highest-value option. Install sentry/sentry-laravel, publish its config, set the DSN, and report exceptions automatically. Add user context and release tags in middleware or in App\Exceptions\Handler.

Pattern B — Build a small in-app bug report flow. If the product requirement is a user-facing "Report a bug" button rather than automatic exception tracking, build it natively:

// routes/web.php
Route::post('/bug-reports', [BugReportController::class, 'store'])
    ->middleware(['auth', 'throttle:5,1']);

// app/Http/Controllers/BugReportController.php
public function store(Request $request)
{
    $validated = $request->validate([
        'message' => ['required', 'string', 'max:5000'],
        'url'     => ['nullable', 'url'],
    ]);

    ReportBug::dispatch(
        user: $request->user(),
        message: $validated['message'],
        url: $validated['url'],
        context: [
            'request_id' => $request->header('X-Request-Id'),
            'user_agent' => $request->userAgent(),
            'app_version' => config('app.version'),
        ],
    );

    return back()->with('status', 'Thanks — your report was submitted.');
}

Then deliver the report through a queued job to email, Slack, Jira, GitHub Issues, or your tracker of choice.

Pattern C — Port logic, not the package. If the legacy Symfony bundle contains useful report-formatting or redaction logic, copy the relevant classes into app/Support/BugReporting, remove Symfony dependency-injection annotations, and adapt configuration access to Laravel's config(). Do not attempt to run the bundle itself inside Laravel.

Integration tips:

• Put report delivery behind a queue to avoid slowing down the user's request.
• Capture request ID, route, user ID, app version, and selected headers — but redact authorization tokens, cookies, and PII.
• Rate-limit public bug-report endpoints.
• Deduplicate reports by fingerprint if you forward them to an issue tracker.
• Keep the report payload schema explicit and versioned.

Gotchas and Tips

• Deprecated and abandoned. The repository explicitly says it has moved, and the last release is from 2017. Do not add it to a new project. Treat it as technical debt if found in an existing one.
• Wrong ecosystem. This is a Symfony bundle. Laravel will not auto-register it, will not inject its services, and will not understand its bundle configuration. There is no Laravel service provider to publish.
• Dependency conflicts are likely. A 2017-era Symfony bundle will often require older Symfony components and PHP versions that conflict with current Laravel and PHP constraints. composer require may fail outright, or may force downgrades elsewhere.
• No maintenance or security response. With 0 stars and 0 dependents, there is effectively no community support. Security issues in abandoned packages will not be patched.
• Do not confuse stars with suitability. The score of 0.06 reflects an unmaintained, deprecated package. Popularity alone is not a quality signal, but zero dependents plus a deprecation notice is a strong stop sign.
• Debugging legacy usage. If you must inspect a Symfony app using it: check composer.lock for the installed version, confirm bundle registration, inspect imported routing, and use the Symfony profiler and container debug commands to locate the bundle's services.
• Extension points are Symfony-specific. Any extension hooks will be Symfony bundle configuration, event dispatchers, or DI service overrides. They do not translate to Laravel's container or event system.
• Migration advice. Replace the bundle rather than bridging it. Start by identifying what the bundle actually did for users — exception capture, a report form, email delivery, or issue creation — and map each behavior to a maintained Laravel-native equivalent. Remove the dependency only after the replacement path is tested.
• Test the replacement path. Verify that exceptions are captured, that user-submitted reports are delivered, that sensitive data is redacted, and that failures in the reporting pipeline do not break the user-facing request.