- How do I change a Laravel API Resource response without editing the resource class?
- Laravel Resource Modifier lets you modify the output of a JsonResource at runtime, so you can add, remove, rename or wrap fields without touching the existing resource definition. You apply the changes fluently before the response is returned, which keeps your resource classes focused and reusable. It plugs into the JsonResource::toResponse() seam, so it stays a presentation-layer concern rather than an architectural change.
- How do I install toneflix/laravel-resource-modifier?
- Install it with Composer using composer require toneflix/laravel-resource-modifier. The package ships a publishable configuration file for project-wide defaults, which you can expose with the standard vendor:publish command. Version 2.0 requires PHP 8.3 or 8.4 and Illuminate 12 or 13, so confirm your application meets those constraints before requiring it.
- Does laravel-resource-modifier support Laravel 10 or Laravel 11?
- No. Version 2.0 declares Illuminate ^12.0|^13.0 and PHP ^8.3|^8.4 only, so Laravel 10 and 11 are not supported. Teams still on Laravel 11 must either upgrade the framework first or pin the 1.x line, which lives under the old vendor name toneflix-code/laravel-resource-modifier and is effectively end-of-life. That split is the main thing to plan for before adopting 2.x.
- How do I hide or add fields conditionally based on the authenticated user?
- Conditional fields are the core use case: modifications can be driven by request context, the authenticated user, or feature flags. You attach the conditions where you build the response, so the decision lives with the request rather than inside the resource class. This is useful for role-based payloads, beta features, or trimming responses for public API consumers.
- What is the difference between this package and using additional() in JsonResource?
- Native Laravel already covers this ground through additional(), withResponse() and response macros, in roughly 50 lines of code. This package wraps that same seam in a fluent API so you can add, hide, rename, wrap and conditionally transform fields without editing resource classes. The trade-off is a third-party dependency with a single maintainer versus a small amount of in-house code that carries no lifecycle risk.
- How do I migrate from 1.x to 2.0 of laravel-resource-modifier?
- The 2.0 release is a hard identity break: the Composer name moves from toneflix-code/laravel-resource-modifier to toneflix/laravel-resource-modifier, and the namespace moves from ToneflixCode\ResourceModifier to Toneflix\ResourceModifier. Practically that means removing and re-requiring the package, rewriting imports across your codebase, and republishing the config file. It is not a routine composer update, and it also requires your application to be on Laravel 12 or 13 first.
- Does it work with ResourceCollection and paginated responses?
- Yes, the package is documented as compatible with both JsonResource and ResourceCollection, so collection responses and pagination metadata pass through the same modification path. Because it hooks the response-building stage rather than the query layer, it does not disturb your data fetching or eager loading. If you rely on custom meta handling, verify behaviour against the 2.0 diff, since the changelog reads as rename-only but that is worth confirming.
- Is the package tested and is Laravel 13 support actually verified?
- The 2.0.0 release adds explicit Illuminate constraints in composer.json, a documented CI matrix for Laravel 12 and 13, Testbench ^10.11|^11.1, and Pest 4. That answers the earlier questions about whether compatibility is enforced rather than merely claimed. Because the package has no dependents, nobody else will hit a breakage before you do, so check that the Laravel 13 matrix entry reflects a genuinely green CI run.
- Is toneflix/laravel-resource-modifier safe to use in production?
- The functional risk is low because it is a stateless presentation-layer utility that intercepts response building and adds no infrastructure. The real risk is lifecycle: it is a solo-maintainer package with no stars or dependents, and the vendor and namespace rename means the older 1.x line is a dead end under a superseded name. Given that the functionality is replaceable with native Laravel code, many teams will prefer to own those few lines rather than depend on a package with bus factor one.
- What are the alternatives to laravel-resource-modifier?
- The closest alternative is native Laravel: JsonResource::additional(), withResponse(), response macros, or a small custom middleware that reshapes the payload. All of these cover the same add, hide, rename and wrap operations without adding a dependency. If you want to keep resources untouched and only need conditional per-request shaping, the native route is usually the lowest-risk choice.