Sentry Bundle Laravel Package

Product Decisions This Supports

First, a scoping correction that belongs in any PM record: the brief frames this as a Laravel/PHP package, but nowo-tech/sentry-bundle is a Symfony bundle. The Laravel analogue is sentry/sentry-laravel, an unrelated project. Any roadmap item this informs should be tagged Symfony, not Laravel.

With that corrected, the package supports these decisions:

• Build vs. buy for observability glue. This is a thin community layer over sentry/sentry-symfony: extra event listeners plus a configuration tree. The decision it genuinely informs is not "adopt this?" but "how much custom Sentry integration code do we actually need?" Reading its listener list is a cheap way to scope our own ~200-line subscriber work.
• Standardization on Sentry for Symfony services. If we are consolidating error tracking across Symfony 6/7/8 apps, this bundle's compatibility matrix (PHP >=8.1, Symfony 6/7/8, now advertised up to 8.1) is a useful reference for what a maintained wrapper looks like at that boundary.
• Upgrade-path risk assessment. For teams moving a Symfony app toward 8.x while holding Sentry integration stable, the bundle documents which config keys and extension points survive the jump (v1.11.2 ships a specific UPGRADING.md#to-1112 anchor, and the release is non-breaking). That is directly reusable even if we never install it.
• Definition of "good enough" engineering hygiene for an in-house fork. v1.11.2 sets an explicit bar we can copy for our own internal component: PHPStan + Rector dry-run in CI, a 99% coverage gate, a release gate that refuses to publish with open PRs, and a written security policy. If we build our own subscriber, this is a reasonable template for what we hold ourselves to.
• Use cases where it fits: low-traffic internal Symfony tools and back-office apps that want request/user context enrichment, breadcrumbs, and PII scrubbing with minimal code — not customer-facing, high-availability systems.
• Use cases it does not support: Laravel roadmaps, multi-tenant DSN routing, sampling policy design, or release-health plumbing. Hosted Sentry features and the official SDK cover those better.

When to Consider This Package

Adopt only under narrow conditions:

• You are on Symfony 6/7/8 and PHP 8.1+, so the compatibility claim holds.
• You already run the official Sentry Symfony SDK and have verified a concrete gap this bundle fills — Sentry has absorbed much of this functionality in-tree over the years, so the overlap must be checked first, not assumed. v1.11.2 is maintenance-only (dependency refresh, demo DB swap to MySQL 8.4, CI gates, security docs, one test-attribute modernization); it adds no capability that changes this gap analysis.
• You treat it as source to vendor or copy, not a versioned dependency. There is still no downstream population absorbing breakage on your behalf. v1.11.2 strengthens the quality argument and weakens nothing, but it does not create a support path.
• The code is small enough for one engineer to audit end to end in an afternoon, and you have an owner willing to maintain a fork.

Look elsewhere when:

• The service is production-critical or revenue-bearing. Single-maintainer profile remains the dominant risk, not code quality.
• The published release dates are 2026-10-13 and later, including a dependency "campaign 2026-10-19" — future dates. v1.11.2 does not resolve this; it extends the pattern, which now reads more like a systematic offset in the indexing pipeline than a one-off publishing error. Either way we cannot verify the maintenance cadence from this dataset. Confirm release dates against the upstream repository directly before adoption, not after.
• You need a published support window, CVE response commitment, or SLA. The new docs/SECURITY.md (attack surface, threat model, dependency policy) is a genuine improvement and worth reading, but a self-published threat model is not an incident-response process — no disclosure SLA, no backport policy, no named security contact appears in the release notes.
• You only need straightforward error forwarding: the official sentry/sentry-symfony bundle plus Sentry's own docs, or Monolog's Sentry handler, will do it with a real support path.

How to Pitch It (Stakeholders)

To executives: This is a small MIT-licensed Symfony add-on that wraps Sentry's official integration with extra listeners and configuration. Licensing cost is zero and evaluation effort is measured in days. New in v1.11.2: the maintainer is demonstrably active — Dependabot-driven dependency refresh, static analysis and a 99% coverage gate in CI, a release gate blocking publication while PRs are open, and a written security policy. That is real evidence of an engaged maintainer and it materially improves the quality signal. It does not change the structural picture: no adoption, no support window, no CVE process, and release metadata we still cannot verify. Recommendation stands — evaluate it as a reference, not as a dependency.

To engineering: Treat it as a pattern library. Its value is a concrete, auditable inventory of event listeners and DI configuration for Sentry enrichment in Symfony — useful input for our own subscriber implementation. v1.11.2 is non-breaking and worth a second look specifically for its engineering scaffolding: the CI job layout (PHPStan, Rector dry run, coverage gate) and docs/SECURITY.md are directly reusable as the quality bar for anything we build in-house. Note the demo now runs the DBAL exception reporter against a real MySQL 8.4 service rather than a SQLite file, which suggests the demo path is actually exercised in CI rather than decorative. Audit surface is still small and the read is still fast.

The ask: Approve a two-day, timeboxed spike to read the listeners and config tree and produce a build-vs-buy recommendation. Default outcome is the official Sentry SDK plus a small in-house subscriber we own, with this bundle's CI and security docs used as our template; adopting the bundle requires the spike to surface a gap that cannot be closed in under a day of our own code.