- What does alt-three/bugsnag actually do?
- It is a thin Laravel service provider that binds the Bugsnag PHP notifier into the container, exposes a facade, publishes a config file, and hooks into the framework's exception handler report() path so uncaught exceptions are forwarded to your Bugsnag dashboard. It owns no data, domain logic, or persistence — just a few hundred lines of glue targeting Laravel 5.x. Architecturally it is disposable by design, which is its only real advantage.
- Is alt-three/bugsnag still maintained?
- No. The last release was 2016-06-20, the repository is archived, and the source has been relocated into a maintainer's personal Deprecated namespace. That is a deliberate end-of-life signal from the original author, not slow drift. The Bugsnag PHP v2 notifier it pins is also end-of-life.
- Does alt-three/bugsnag work with Laravel 9, 10 or 11?
- No. It targets Laravel 5.0 through 5.4 on PHP 5.5 through 7.0, and its manifest pins illuminate/support to the 5.x line. On Laravel 6 and later, Composer resolution will fail outright or require --ignore-platform-reqs, which turns a clean install problem into a runtime landmine. Use the vendor's bugsnag/bugsnag-laravel package for any supported Laravel version.
- How do I install alt-three/bugsnag?
- In principle you would run composer require alt-three/bugsnag, register the service provider, and publish the config file. In practice it only resolves cleanly on a Laravel 5.x application running a matching PHP version — an environment nobody should be running today. Installation is not recommended.
- What should I use instead of alt-three/bugsnag?
- The vendor's own bugsnag/bugsnag-laravel package superseded this bridge and is actively maintained. It occupies the same architectural slot — service provider, facade, config, exception handler hook — so the conceptual swap is trivial. If Bugsnag itself is not mandated, treat this as a stack-selection decision and compare Sentry, Rollbar, Flare, or cloud-native tooling.
- How do I migrate from alt-three/bugsnag to bugsnag/bugsnag-laravel?
- Install the current official package, then port your config: API key, release stage, notify release stages, and filters. The provider and facade names change, so update the registrations in config/app.php and any facade imports. The real work is operational — revalidating that errors actually arrive — rather than the code change itself.
- Does alt-three/bugsnag run on PHP 8?
- Almost certainly not. The code dates from 2016, when constructs removed in PHP 8.0 were still in routine use, and its pinned transitive dependencies such as Guzzle and Symfony components are equally old. Even if it loads, nothing in the package has been tested against a modern runtime.
- How do I configure the Bugsnag API key in a Laravel app?
- This package publishes a config file where you set the API key, environment or release stage, and notification and filtering options. With the current official package you do the same thing through config/bugsnag.php and environment variables. Keep the key out of source control and set per-environment values.
- Does alt-three/bugsnag automatically report exceptions to Bugsnag?
- Yes — it wires into Laravel's exception handler report() path so uncaught exceptions are forwarded to Bugsnag with context. The problem is that with an out-of-date v2 notifier pinned to 2016-era ingest endpoints, failure is silent: errors simply stop arriving and nobody notices until an incident.
- Is alt-three/bugsnag safe to use in production?
- No. The repository is archived, so there is no CVE monitoring, no patch releases, and no coordinated disclosure path, while frozen 2016-era dependencies carry any vulnerabilities they had forward indefinitely. There is also no community around it — roughly 10 stars and zero dependents — so no third party has validated the code. Use it only as a reading reference for how the exception handler hook is wired.