Laravel Resource Modifier Laravel Package

Product Decisions This Supports

• Build vs. buy on API serialization: the package's job is to modify Laravel API/Eloquent resource output (shape, add/remove/rename fields per context) without forking resource classes. This is exactly the kind of small, well-bounded utility where a dependency beats an in-house trait/macro — provided you accept the maintenance and vendor-risk profile below.
• API versioning & backwards compatibility: enables serving different payload shapes to different consumers (v1 vs. v2 clients, admin vs. public, mobile vs. web) from the same underlying resources — a lever for deprecating fields gradually instead of doing a hard breaking API change.
• Roadmap coupling to the framework upgrade: 2.0.0 requires Laravel 12 or 13 and PHP 8.3+. Adoption of 2.x is therefore a consequence of your framework/PHP upgrade plan, not an independent decision. If Laravel 12/13 is on the roadmap, this release removes a blocker; if it isn't, 2.x is not available to you and 1.1.5 is the terminal version for your stack.
• Breaking-change budget allocation: 2.0.0 is a hard rename — package toneflix-code/laravel-resource-modifier → toneflix/laravel-resource-modifier and namespace ToneflixCode\ResourceModifier → Toneflix\ResourceModifier. Any team on 1.x must schedule a migration ticket (composer remove/require, import updates, republished config, CI/deploy cache invalidation). This is migration work, not a feature win — price it accordingly.
• Supply-chain/vendor risk acceptance: the move to a single toneflix vendor namespace plus a major version with no new user-facing features suggests a housekeeping/consolidation release. Treat ongoing reliance on a small, single-vendor package as an explicit accepted risk with a documented exit path (see below).

When to Consider This Package

Adopt when:

• You are on, or imminently moving to, Laravel 12/13 with PHP 8.3+ — that is a hard prerequisite for 2.x.
• You repeatedly find yourself writing ad-hoc conditionals inside resource classes (or whenLoaded/when sprawl) to reshape payloads for different consumers.
• You want per-endpoint or per-client response shaping with a thin surface area — i.e., you don't need a full transformation/serialization layer.
• You're willing to pin the version and own a small migration on each major.

Look elsewhere / defer when:

• You're pinned to Laravel ≤11 or PHP ≤8.2. Stay on 1.1.5 (frozen) or don't adopt — 2.x will not install.
• A vendor rename has no appeal and no other reason to move. If 1.1.5 is working and the framework upgrade isn't funded, there is no functional pull to 2.0.0; defer.
• You need a heavyweight, contract-first transformation layer — schema-driven serialization, versioned API specs, media/relationship includes — or commercial support and SLAs. Prefer a dedicated transformer/serializer stack or Laravel's native resources plus explicit DTOs.
• Your governance requires maintained, multi-contributor dependencies or audited releases: a small single-vendor package with a namespace churn event is a yellow flag, not a red one, but it must be tracked.
• The logic is trivial (one or two field tweaks): a local macro or plain when() is cheaper than a dependency plus its migration cost.

Adoption gate for 2.x specifically: confirm composer can resolve the new name, then run the upgrade as a single atomic step — composer remove toneflix-code/laravel-resource-modifier followed by composer require toneflix/laravel-resource-modifier:^2.0, then replace ToneflixCode\ResourceModifier imports and republish the config. Watch for stale config caches and CI artifacts that still reference the old namespace.

How to Pitch It (Stakeholders)

For executives (one-liner): a small utility that lets us change API response shapes per client without rewriting resources — it avoids bespoke glue code, and its new major version lands in lockstep with our Laravel 12/13 upgrade. The cost is a one-time package/namespace rename on our side.

For engineering: version 2.0.0 is a rename + platform bump, not a feature release. Highlights:

• Package renamed to toneflix/laravel-resource-modifier; namespace now Toneflix\ResourceModifier.
• Requires PHP ^8.3|^8.4 and Illuminate ^12.0|^13.0 (Laravel 13 support added).
• Dev tooling moved to Testbench ^10.11|^11.1 and Pest ^4; README and CI matrix updated for Laravel 12/13 — no runtime behaviour changes called out.
• Migration is mandatory and mechanical: remove/require the package, update imports, republish the published config, clear caches, verify the CI matrix.

Recommendation: approve the migration only as part of the Laravel 12/13 upgrade workstream, with 1.1.5 staying frozen for any app not yet upgraded. Track the vendor rename as a minor supply-chain signal and keep a documented fallback (native resources + conditional attributes) in case the package stalls.