Eh Symfony Laravel Package

Product Decisions This Supports

• Build vs. buy for error handling. Exception-to-response rendering, debug pages, and error logging are undifferentiated plumbing. This package is a candidate to adopt rather than maintain in-house, freeing engineering capacity for product work.
• Roadmap sequencing for platform upgrades. v1.1.0 adds Symfony 7 compatibility while retaining prior support. That makes the package a viable dependency to carry through a framework modernization cycle instead of a blocker that forces a fork or replacement mid-upgrade.
• Scope clarification for "PHP package" vs. "Laravel package." This is a Symfony integration (an eh-* family adapter wrapping the shared Exception Handler core). For a Laravel-first product it is not a direct dependency — the relevant decision is whether the team's non-Laravel PHP services (workers, internal tools, admin backends, legacy satellites) should standardize on the same error-handling behavior. If yes, adopt the family consistently; if no, this is out of scope for the Laravel roadmap.
• Consistency and support-burden trade-offs. A single error-handling contract across services simplifies on-call runbooks, support escalation, and incident triage. The PM decision is whether that consistency is worth one more third-party dependency in the supply chain.
• Feature framing for internal tooling. If the team ships internal Symfony-based dashboards or APIs, this supports "make failures legible" work — predictable status codes, environment-gated stack traces, and structured error payloads — without writing that logic per service.

When to Consider This Package

Consider adoption when:

• Your stack includes Symfony 6.4 or 7.x services (PHP 8.2+), and you want consistent exception rendering without bespoke handlers per service.
• You already use, or plan to use, other adapters from the same eh-* family and want uniform behavior across frameworks.
• The team is small and error-page/exception-mapping maintenance is a recurring, low-value tax.
• You need a drop-in, permissively licensed dependency with a narrow surface area — low integration risk, easy to remove later.

Look elsewhere when:

• The product is a pure Laravel application. Use Laravel's native exception handler plus a Laravel-native adapter or debug tooling; adding a Symfony bundle buys nothing and adds a moving part.
• You need production-grade telemetry, alerting, or error aggregation — that's Sentry/Bugsnag/OpenTelemetry territory, not this package's job. Treat it as a rendering/response layer, not an observability strategy.
• You require vendor SLAs, security review artifacts, or a formal support contract; this is a single-maintainer community package.
• Your error contract is domain-specific and heavily customized (per-tenant error taxonomies, regulatory message requirements) — you'll end up overriding most of the defaults anyway.

Release-specific read on v1.1.0: Symony 7 compatibility only. No new public API, no deprecations, no breaking changes. It is a maintenance/longevity signal — evidence the package tracks current framework releases — rather than a feature that changes the product calculus. Upgrading is low-risk and recommended for anyone already on the 1.x line; teams on Symfony 5.x or below should confirm their supported-version floor before committing.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated a small open-source PHP package for standardizing how our services surface errors to users and logs. The new release adds support for the current Symfony version, which means the dependency stays viable through our next framework upgrade instead of becoming a migration liability. It is permissively licensed, narrow in scope, and cheap to remove — a low-risk way to stop paying engineers to hand-maintain error pages. For our Laravel core product it is not a direct fit; the value is in our secondary PHP services, and only if we choose to standardize error handling across them.

For engineering (summary): v1.1.0 is additive compatibility with Symfony 7 — no breaking changes, no deprecation, no API surface change. Treat it as a patch-level bump: update the constraint, run the suite, and verify error rendering and debug/production environment gating in staging. Confirm the minimum supported Symfony version in composer.json before bumping so no service silently drops below the floor. If we adopt, pin the minor version and revisit at each Symfony LTS. If we do not have Symfony services in the estate, we should close this out and instead evaluate the Laravel-native equivalent so the decision is recorded rather than re-litigated.