- What is alt-three/sentry and what does it do?
- It is a thin Laravel 5 bridge over the v1.x Sentry PHP SDK. It registers a singleton Sentry client from a published config file, exposes a Sentry facade alias, and hooks Laravel's exception handler so uncaught exceptions in App\Exceptions\Handler are forwarded to Sentry. It is glue for error reporting, not a standalone error-tracking implementation.
- Is alt-three/sentry compatible with Laravel 9, 10, or 11?
- No. The realistic compatibility envelope is Laravel 5.0 through 5.2 on PHP 5.5 or 5.6, which means any consuming application is already past end of life. Adopting it on a modern Laravel and PHP 8 stack would require forking and rewriting the service provider, config schema, and transport layer. Use the officially maintained sentry/sentry-laravel package instead.
- How do I install alt-three/sentry in a Laravel 5 application?
- On a legacy Laravel 5.0 to 5.2 application running PHP 5.5 or 5.6, require alt-three/sentry with Composer, register the package service provider and Sentry facade alias in config/app.php, publish the package config, and set your Sentry DSN. Modern Composer constraints and PHP versions will typically block installation. This package is archived, so treat installation as legacy-only work.
- Is alt-three/sentry still maintained?
- No. It has been archived since 2016, with its last release on 2016-06-04, 7 stars, and zero dependents. There is no maintainer, no bug-fix cadence, and no CVE responsiveness. Treat it as abandoned technical debt rather than a supported integration.
- What should I use instead of alt-three/sentry?
- Use sentry/sentry-laravel, the officially maintained Laravel integration. It occupies the same architectural slot with a service provider, facade, publishable config, and exception-handler integration, but supports current Laravel and PHP versions. Choosing the archived bridge over the first-party package buys nothing and costs you a fork.
- How do I migrate from alt-three/sentry to sentry/sentry-laravel?
- First inventory the constraint set with composer why alt-three/sentry and search application code for the Sentry facade alias, app('sentry'), and direct SDK calls. Then remove the bridge, require sentry/sentry-laravel, and publish the new config. Config keys do not map one-to-one, so review the DSN, environment, and handler wiring carefully. Facade-only usage is mostly find-and-replace, while direct raw SDK calls are the expensive case.
- Does alt-three/sentry still send events to a current Sentry DSN?
- Ingestion may still function against a current DSN, but the package is unsupported and the resulting events are low-fidelity. The v1 SDK predates envelopes, breadcrumbs, release and health tracking, tracing, and modern sampling controls. There is no compatibility shim to the official SDK, so do not rely on this behavior in production.
- How do I configure the DSN and exception handler in alt-three/sentry?
- Publish the package config and set your Sentry DSN there, then make sure the provided exception-handler hook forwards uncaught exceptions from App\Exceptions\Handler to Sentry. The package also exposes a Sentry facade alias for manual reporting. It has no modern before_send scrubbing hooks, so any PII or GDPR controls must be built separately around an unmaintained dependency.
- Is alt-three/sentry safe to use in production on PHP 8?
- No, the technical risk is high and non-mitigable. PHP 5-era code on PHP 8 can fail on deprecated dynamic properties, removed functions such as each(), and signature variance, and the worst failure mode is a 500 in your exception path rather than Sentry simply stopping. With no maintenance or CVE responsiveness, it should not be adopted for production.
- How do I test that alt-three/sentry is reporting exceptions?
- In a legacy Laravel 5 environment, verify the DSN and handler wiring, then trigger a test exception and confirm the event appears in Sentry. There is no community test surface or incidental bug discovery, and the package cannot be reliably run on modern PHP 8, so testing is limited to the old stack. If the event is low-fidelity or missing, migration to sentry/sentry-laravel is the correct fix.