- Is riper/exception-transformer a Laravel package?
- No. As of v2.0.0 it ships as a Symfony bundle (RiperFr\ExceptionTransformerBundle) that hooks Symfony's HttpKernel kernel.exception event, and the release notes mention no Laravel service provider, facade, or framework-agnostic entry point. Laravel owns exception handling through App\Exceptions\Handler and the Illuminate\Foundation pipeline, so there is no kernel-event seam for this bundle to attach to.
- How do I install riper/exception-transformer in a Laravel application?
- You can attempt composer require riper/exception-transformer, but expect dependency conflicts: the package's Symfony 4 platform constraints do not line up with the Symfony 6/7 components Laravel 10 and 11 require. Even if resolution succeeds, nothing registers in Laravel because there is no service provider. Making it work would mean importing Symfony HttpKernel and EventDispatcher and re-implementing behavior Laravel already provides.
- Does riper/exception-transformer support Laravel 10 or Laravel 11?
- No. v2.0.0 sets PHP 7.4+ and Symfony 4 as its floor, while Laravel 10 and 11 target PHP 8.1/8.2 and Symfony 6/7. The release notes do not reference Laravel, a service provider, a facade, or a framework-agnostic transformer contract, so there is no supported integration path.
- What does riper/exception-transformer do?
- It maps exception classes to tailored responses: custom messages, HTTP status codes, and payload formats, so API error output stays uniform. You register custom transformers for domain exceptions through Symfony's bundle and DependencyInjection extension model. The design goal is lean controllers and consistent JSON errors, and it accomplishes that within Symfony's kernel.exception flow.
- Can I use riper/exception-transformer to return consistent JSON errors from a Laravel API?
- Not natively. The capability you want — normalizing exception output into one JSON envelope — is exactly what Laravel's Handler renderers do, via renderable() closures, custom renderers, Responsable responses, and report() overrides. Define your own ExceptionTransformer contract with toArray()/normalize() and wire it into App\Exceptions\Handler::register(); keep the framework-specific code behind the interface so it stays replaceable.
- How is riper/exception-transformer configured?
- Through Symfony bundle conventions: bundle registration, DependencyInjection compiler passes, and YAML or XML configuration. Laravel's bootstrap does not honor that extension model, so none of the package's configuration surfaces apply in a Laravel app.
- Is riper/exception-transformer production-ready and actively maintained?
- Signals are weak: 0 stars, 0 dependents, a score of 0.03, a bus factor of one, no security policy, and no response process. v2.0.0 is a genuine versioned release with a BC contract and CI moved to GitHub Actions, but it is the first activity since 2021 and it modernizes to a baseline (PHP 7.4, Symfony 4.4) that is already end-of-life. Because exception transformation sits on the error path, defects risk unhandled fatals, masked stack traces, or leaked internals. If you fork it, you own it when the next PHP or Laravel upgrade breaks it.
- What are the Laravel-native alternatives for mapping exceptions to JSON responses?
- Use App\Exceptions\Handler with renderable() closures or a custom renderer per exception type, return Responsable responses for API envelopes, and override report() for logging and PII scrubbing. Add a small internal transformer class behind a toArray()/normalize() contract when you need reusable payload shaping. This covers error normalization and consistent JSON with no third-party dependency.
- Is v2.0.0 a breaking change, and is there a migration path from v1?
- Yes. The v2.0.0 notes list three BC bullets with no upgrade path, changelog link, or deprecation notice — a documentation gap on the highest-severity surface, error handling. It only matters if you have a v1 footprint; a new Laravel adopter has none, so there is no migration cost and also no adoption reason.
- How do I test exception-to-JSON mapping in a Laravel app?
- Use Laravel's HTTP test helpers to assert status codes and JSON structure for each exception class you map, and unit-test the transformer contract directly with toArray()/normalize() inputs. If you evaluate this package, note there is no Laravel test harness, service provider, or binding to assert against, so any test coverage would be for code you wrote yourself.