- Can I install nowo-tech/sentry-bundle in a Laravel application?
- No. This package is a Symfony bundle: it ships a Bundle subclass, a DependencyInjection extension, a Symfony Configuration tree, and kernel/console event subscribers. Laravel has no bundle auto-discovery or Symfony-style Configuration tree, and its Sentry integration is sentry/sentry-laravel, built on the same sentry/sentry core with its own service provider and config file. Treat this repo as a pattern source for Laravel, not a Composer dependency.
- Which Laravel versions does nowo-tech/sentry-bundle support?
- None. It is a Symfony bundle, not a Laravel package, so there is no Laravel version compatibility to check. For Laravel, use sentry/sentry-laravel instead. For Symfony, read the composer.json constraints for PHP and Symfony versions and confirm the CI matrix yourself, since a PHP 8.1-8.4 by Symfony 6/7/8 matrix is not documented in the assessment.
- What does this bundle add over sentry/sentry-symfony?
- The stated differentiator is enhanced event listeners and a richer configuration surface: request, user, and console context extraction, breadcrumb augmentation, filtering, and opinionated enrichment beyond upstream defaults. However, it is not clear from the available context whether it wraps sentry/sentry-symfony or reimplements the integration from scratch, which matters for inheriting upstream security fixes. With zero stars and zero dependents, those listener semantics are not battle-tested by third parties. Ask the maintainer before relying on it.
- How do I install and configure it in a Symfony app?
- The normal path is composer require nowo-tech/sentry-bundle, enable the bundle in config/bundles.php, and configure it through the bundle's Configuration tree under config/packages. The DSN and environment-specific options should come from environment variables rather than committed YAML. For Laravel there is no equivalent config/sentry.php merge: you must re-express the settings in sentry/sentry-laravel's config file if you port any logic.
- Will it create duplicate Sentry events or breadcrumbs?
- That is a real risk. Enhanced listeners layered over an existing SDK can emit duplicate events, duplicated breadcrumbs, or duplicate transaction spans, which inflates quota and pollutes issue grouping. Ask which listeners are additive versus duplicative of Sentry defaults, and confirm each one is individually toggleable via config. Validate in staging with a quota guard before enabling in production.
- Does it capture PII such as request headers, cookies, or request bodies?
- Possibly, and this is the highest-severity adoption risk. Enrichment listeners are the most common place request headers, cookies, and bodies leak into Sentry, and the assessment found no documented scrubbing or PII story. Review every listener's attached data and configure beforeSend or Sentry's data scrubbing with explicit allowlists. Do not roll it out default-on without a privacy review.
- Is nowo-tech/sentry-bundle production-ready and actively maintained?
- The signals are weak: zero stars, zero dependents, no downstream bug reports, and a bus factor that appears to be one. The last-release date of 2026-10-13 is in the future, which looks like a tagging, clock, or automation anomaly until verified, so tag semantics cannot be trusted for pinning. The license is MIT, which is fine, but there is no published support window. Until you verify provenance and tags, fork or vendor the code rather than pinning to it.
- Can I use it in a monorepo that also contains sentry/sentry-laravel?
- Expect Composer constraint collisions. Extending Sentry means hard constraints on sentry/sentry and presumably sentry/sentry-symfony, and those will fight sentry/sentry-laravel's constraints in a shared lockfile. Plan separate Composer roots and lockfiles per runtime. Split the decision by runtime, not by team: Symfony services can adopt the bundle normally, while Laravel apps should not depend on it.
- Which parts of this bundle can I port to Laravel?
- The HTTP-side listeners port nearly 1:1 because they sit on Symfony HttpFoundation, which Laravel also uses via illuminate/http, and on Sentry's public Event and Scope API rather than framework-private internals. The console-side listeners do not port cleanly: Symfony ConsoleEvents differ from Laravel's Artisan and console event plumbing. Configuration must be re-expressed as a config/sentry.php merge rather than a YAML tree, and you should read src/DependencyInjection, src/Configuration.php, and the listener classes first.
- What should I ask the maintainer before adopting it?
- Ask whether it wraps sentry/sentry-symfony or reimplements integration from scratch, since that determines whether it inherits upstream security fixes. Ask which listeners are additive versus duplicative and whether each is individually toggleable, what data each listener attaches, and what the documented scrubbing and PII story is. Also confirm the CI matrix (PHP 8.1-8.4 by Symfony 6/7/8), listener test coverage, whether semver is honored for config keys and public service IDs, the support window, and what actually shipped in the anomalous 2026-10-13 release.