Exception Transformer Laravel Package

Product Decisions This Supports

• Error-handling architecture and API error contracts: Informs decisions about where in the request lifecycle exceptions get normalized into consistent, user-safe responses (problem+json, RFC 7807, or a house error envelope) rather than leaking stack traces or vendor-specific messages.
• Build vs. buy vs. borrow: Frames whether to assemble exception transformation from native framework primitives (a kernel.exception listener/subscriber in Symfony, or a Laravel exception handler's render/report hooks) versus depending on a third-party bundle for the same intercept point. The v2.0.0 release is maintenance-only (BC breaks, CI migration) and adds no capability, which tips this decision firmly toward build.
• Observability and incident response roadmap: Clarifies whether exception transformation is a distinct product concern (mapping internal failures to external status codes, redaction, correlation IDs for logs/support) that belongs on the platform/API-consistency roadmap rather than as a one-off patch.
• Multi-surface consistency: Supports decisions about keeping web, API, and mobile clients on a shared error taxonomy, which affects API versioning, SDK generation, and client-side retry/UX behavior.
• Prioritization of technical debt: Helps a PM rank "abandoned dependency risk" against feature work — a zero-adoption package that only just reached PHP 7.4 / Symfony 4 compatibility is a maintenance liability with no offsetting feature value.
• Use-case screening: Confirms whether "transform an exception before the kernel catches it" is a real requirement (rare — most needs are satisfied by post-catch listeners) or an over-engineered framing of standard error mapping.

When to Consider This Package

• Only if you are on a legacy Symfony application (4.x-era) with a genuinely pre-kernel interception requirement that cannot be met by the standard kernel.exception event, and you have a hard constraint preventing you from writing a small listener.
• Only if you are willing to vendor-fork it: stars are 0, dependents are 0, and the composite score is 0.03 — there is effectively no community validation and no evidence of production use. The v2.0.0 release improves the maintenance hygiene signal slightly (GitHub Actions replacing Scrutinizer) but does not change the adoption or support picture.
• Compatibility caveat (now sharper): the release notes confirm the package is a Symfony bundle (ExceptionTransformerBundle), not a Laravel package — it is not drop-in usable in a Laravel application. v2.0.0 raises the floor to PHP ≥7.4 and Symfony ≥4 but declares no PHP 8 or Symfony 5/6 support. Since current Laravel (9+) and Symfony (5.4+) require PHP 8.0+, adopting this would force or risk pinning an end-of-life runtime. Verify against your actual framework/PHP matrix before any spike.
• Look elsewhere in the overwhelming majority of cases:
  • Symfony: a small EventSubscriberInterface on KernelEvents::EXCEPTION, or API Platform's error handling / ErrorListener.
  • Laravel: the framework's Handler::render() / report() overrides, or a package with active maintenance for API error envelopes.
  • Cross-cutting: a shared error-mapping service behind an interface, so the interception strategy is an implementation detail you can swap.
• Do not consider it for new builds, anything with an SLA, or anywhere supply-chain and security review is mandatory.

How to Pitch It (Stakeholders)

Executives: This is a small, effectively unmaintained third-party Symfony bundle (zero stars, zero downstream dependents, composite score 0.03) that nominally helps standardize how application errors are converted into user-facing responses. Its latest release, v2.0.0, is housekeeping only: breaking changes to drop PHP <7.4 and Symfony <4, Symfony 4 compatibility, and a move from Scrutinizer to GitHub Actions. No new functionality, and still no PHP 8 or Symfony 5/6 support. The capability is worth having; this package is not worth adopting — and it isn't even a Laravel package, so it cannot serve our primary stack. Recommendation: do not take on the dependency. The same outcome is achievable with a few dozen lines of first-party code on framework-native hooks, which removes the maintenance, security-review, EOL-runtime, and bus-factor risk at negligible cost.

Engineering: The requirement — transform exceptions into a consistent, redacted error contract — is legitimate and belongs in our platform standards. The proposed mechanism (intercepting before the kernel handles the exception) is non-standard and offers no advantage over a kernel.exception subscriber. The v2.0.0 release is a BC-only modernization to PHP 7.4 / Symfony 4 that lands behind our current runtime baseline (PHP 8.1+, Symfony 5.4+/6, Laravel 10/11), so it cannot be adopted without downgrading or forking. Given the package's abandonment, zero adoption, and version incompatibility, we should implement error transformation in-house behind a narrow interface: map domain exceptions to HTTP/problem types, log the original with a correlation ID, and render the sanitized form. This keeps us framework-idiomatic, testable, and free of an unmaintained dependency — and it's a small, well-scoped slice of work rather than a roadmap item.