Problem Details Symfony Bundle Laravel Package

Product Decisions This Supports

• Public API error contract (the real decision). Adopting RFC 9457 is a product commitment, not a library choice: type URIs, title, and status become a versioned surface that partner integrators, SDKs, and dashboards key on. Once shipped, changing a type URI is a breaking change with a deprecation cycle. This package is a vehicle for that decision — the decision outlives the package.
• Roadmap item: "API maturity / enterprise readiness." Standardized, machine-readable errors are a recurring checkbox in security questionnaires, partner onboarding reviews, and API style-guide compliance. This is a cheap, visible tick for a platform/API initiative, and it is usually scoped under developer experience rather than under a feature.
• Build vs buy — and here the honest answer skews to build. The capability is one exception listener plus a response factory mapping exceptions to status/type. That is roughly 1–2 engineer-days of code we own forever. What the package genuinely adds is configuration-driven exception→problem-type mapping; if we only have a handful of exception classes, a hand-written map is cheaper than a dependency review.
• Symfony-native check before any spend. Symfony's error handler already emits application/problem+json via ProblemNormalizer in production error responses. Before funding adoption, confirm what the framework gives us free — the incremental value of a third-party bundle over core may be limited to the per-exception type-URI mapping.
• Use cases where it earns its place: public/partner-facing REST APIs, a multi-service platform where several services must return an identical error shape, generated client SDKs, and error analytics keyed on type. Use cases where it does not: internal-only services, GraphQL APIs (different error model), or teams with fewer than ~5 distinct exception types.
• Stack mismatch flag. This is a Symfony bundle, not a Laravel package. For a Laravel roadmap the decision is "adopt the RFC as a middleware of our own," using the underlying phauthentic/problem-details library or equivalent — the bundle itself is not adoptable.
• Spec currency. The description cites both RFC 7807 and RFC 9457. RFC 9457 obsoletes 7807. Anyone pitching this should be pitching 9457 and verifying the package actually follows it, since 7807-era tooling is what most of the ecosystem still emits.

When to Consider This Package

Consider it when:

• The application is Symfony 6.4/7.x and there is a real, external API consumer whose error handling we care about.
• We want exception→problem-type mapping to be configuration rather than code, and we have enough exception variety that a hand-rolled map would be unwieldy.
• The team has already standardized on the phauthentic/problem-details library, so the bundle is an adapter over a dependency we've accepted.
• We have a dependency-governance process that can absorb a low-activity dependency on a non-critical path, with an internal wrapper so removal is a one-file change.

Look elsewhere when:

• The stack is Laravel. This bundle is irrelevant; the decision collapses to "do we implement RFC 9457 middleware ourselves?" (Answer: usually yes, and it's small.)
• The bar is a supply-chain threshold. 1 star, 0 dependents, a single maintainer, and an empty changelog on the 1.0.0 release fail most reasonable adoption gates. A package on the error path of every request is a high-blast-radius place to carry that risk.
• Symfony core already covers the need. If ProblemNormalizer output is close enough, the cheapest correct move is to align with it and add a thin mapping layer for type URIs.
• We need support guarantees. Security SLAs, an LTS commitment, or a vendor to escalate to are not available here; assume self-support and plan to fork if needed.
• Only a handful of error shapes exist. Below roughly five exception types, in-house code wins on total cost of ownership by a wide margin.

Recommendation: adopt the pattern, not the package. Implement RFC 9457 responses as a small internally owned listener/middleware, optionally taking the underlying problem-details library as a low-risk leaf dependency. Revisit this bundle only if our exception-mapping surface grows to the point where configuration beats code — and only after the maintainer publishes a changelog and demonstrates a framework-upgrade track record. Re-evaluate at the next Symfony major.

How to Pitch It (Stakeholders)

Executive summary (30 seconds). RFC 9457 is the current standard for machine-readable API errors, and it's worth adopting — it removes ambiguity for partners and ticks a box in enterprise reviews. This specific package is not the way to do it: a single-maintainer, 1-star Symfony bundle with no changelog sitting on the code path of every request. The capability is small enough to own: roughly two engineer-days, no lock-in, no supply-chain exposure. Recommendation: fund the standard, not the dependency.

To engineering. We're standardizing error payloads on RFC 9457 (type, title, status, detail, instance). Implement it as our own exception listener plus a ProblemDetails response factory, with exception→type-URI mapping in config. Take a leaf library only if it stays swappable behind our own interface. Note that the evaluated bundle is Symfony-only and can't be used here regardless — and that Symfony's ProblemNormalizer should be checked first to avoid duplicating what we get free. Contract-test the error shape so it becomes a regression surface rather than an aspiration.

To commercial / partnerships. Partners and SDK consumers get a stable, documented error schema instead of our ad-hoc JSON. We commit to type URIs as a versioned interface: additions are non-breaking, any change to an existing type gets a deprecation window. We should say this explicitly to API consumers, because the commitment — not the implementation — is what the partner integration team cares about, and the commitment is what we must not casually break later.

Risk framing, if asked why not the package. The failure mode is not that it breaks today; it's abandonment at the next Symfony major, combined with a 1.0.0 shipped without release notes so upgrade behaviour is unverifiable. On a global exception path, that risk is paid on every request. Our mitigation — owning the ~150 lines — costs less than the review, monitoring, and eventual migration the dependency would require.

Ask. Approve the two-day build under the API maturity roadmap item; approve the public error-schema versioning policy alongside it; and record the decision to decline the package so it isn't re-litigated at the next dependency sweep.