- Is soft-passio/api-exception-bundle a Laravel package?
- No. It is a Symfony bundle built around a kernel.exception listener, so it hooks Symfony's HTTP kernel rather than Laravel's exception pipeline. Laravel routes exceptions through App\Exceptions\Handler and Illuminate\Foundation\Exceptions\Handler, which this package does not touch. Installing it in a Laravel app will not change your API error responses.
- Can I install soft-passio/api-exception-bundle with Composer in a Laravel project?
- Composer may resolve it, but it will not register itself or intercept Laravel exceptions. Laravel only auto-discovers service providers, not Symfony bundles, so there is no integration point out of the box. Even if you manually wired the listener, it expects Symfony kernel events and HTTP foundation objects that Laravel's handler does not emit in that shape.
- Which Symfony and PHP versions does api-exception-bundle support?
- The last release was June 2020, which points at Symfony 4/5 and PHP 7.x-era constraints. Symfony 6 and 7 changed the exception listener signature, replacing GetResponseForExceptionEvent with ExceptionEvent, so expect fatal errors or deprecations on modern runtimes. Check the composer.json constraint set against your symfony/http-kernel version before assuming it installs.
- Is soft-passio/api-exception-bundle still maintained?
- There has been no release since June 2020, and the repository shows zero stars and no dependents. That means no upstream bug fixes, no CVE response path, and no one validating it against current Symfony or PHP versions. If you adopt it, you effectively become the maintainer of vendored code.
- How do I return RFC 7807 problem+json error responses in Laravel?
- Implement it first-party in App\Exceptions\Handler rather than pulling in a Symfony bundle. Override render or register a renderable closure that maps exceptions to a status code and a consistent application/problem+json body. This typically takes roughly 40 to 80 lines, stays versionless, and keeps the behavior under your own tests and security review.
- Does the package leak stack traces or internal exception messages in API responses?
- That is the exact risk area to review, because error-to-JSON conversion is where internal details escape. The package has had no maintenance since 2020, so there is no recent security review or CVE response path behind it. Whatever you use, verify that production responses strip traces, file paths, SQL, and raw exception messages before shipping.
- Will it conflict with logging, Sentry, or the Symfony profiler exception listeners?
- That interaction is unverified. Multiple kernel.exception listeners run in priority order, and an error-rendering listener that does not set a response can leave later listeners to overwrite or duplicate output. Test the combined behavior in staging with your logging and error-tracking stack enabled before relying on it.
- How does it compare to Symfony's ProblemNormalizer or a custom kernel.exception subscriber?
- Both alternatives are maintained and far more predictable. A custom subscriber or Symfony's ProblemNormalizer gives you the same RFC 7807 output with full control over status mapping and redaction. Given the bundle is small and abandoned, writing the equivalent yourself is a better trade than depending on it.
- How should I test exception-to-response mapping?
- Write unit tests that assert each exception type maps to the expected HTTP status and media type. Add explicit leakage tests that trigger real exceptions with sensitive payloads and assert traces, messages, and file paths never appear in the body. If you fork the bundle, pin the commit and put these tests around the listener so upgrades are safe.
- What is the recommended migration path if someone already mandated this bundle?
- Vendor or fork it into the repository, pin the exact commit, and add tests around the listener so it becomes owned code with a known surface. Run a short spike against a staging Symfony app to capture install results, behavior, and conflicts. If the spike shows any incompatibility, default to a first-party listener and roll it out behind a feature flag while comparing against current error responses.