Laravel Resource Modifier Laravel Package

Product Decisions This Supports

• API contract shape: per-endpoint vs. per-consumer meta. The package gives you one interception point to mutate the meta block of Eloquent API Resource responses, which turns "should mobile get pagination counts?", "should partners see rate-limit hints?", "should white-label tenants see our brand in meta?" from a per-Resource-class code change into a configuration/policy decision. That is a product decision you can now make and reverse cheaply — provided your platform floor matches the package's (Laravel 12/13, PHP 8.3+; see below).
• Build vs. buy vs. copy. The surface area here is small (meta mutation on resource responses). Treat this as a make-vs-buy decision on a 50–200 line concern, not a platform bet: evaluate it against a house middleware/response macro, a JsonResource::wrap/additional convention, or spatie/laravel-data. The package's value is mostly as a reference implementation and a naming convention for your team.
• Framework-version gating as a product constraint (new in 2.0). 2.0.0 requires PHP ^8.3|^8.4 and Illuminate ^12.0|^13.0, and drops everything older. That makes adoption a platform roadmap decision, not just a code decision: it's only available to squads already on Laravel 12, or on a committed path to it. If half your fleet is on 10/11, this is not a per-squad convenience anymore — it's a fork or a wait.
• Feature work it unblocks: client-specific response profiles (web / mobile / partner / internal), deprecating meta fields without shipping v2 resources, injecting request IDs, timing, cache-hit flags, and experiment/cohort tags into responses for observability and A/B analysis, and stripping noisy pagination metadata from endpoints that don't paginate.
• Roadmap scoping: decide whether "response shaping" is a platform capability owned by the API team or a per-squad convenience. Packages like this quietly become de facto platform standards if you let three teams adopt them independently — pick deliberately.
• Adoption risk register: still essentially zero stars and zero dependents; the 2.0 release reinforces the "vendored snippet, not a supported dependency" read. The namespace-and-vendor rename mid-life is exactly the kind of churn you don't want to inherit transitively — it's a rename of both the Composer package and the PHP namespace, plus the published config reference, in a single major. Budget for forking on day one and taking the rename in your fork immediately.

When to Consider This Package

Adopt (or, more accurately, evaluate in a one-day spike) when all of these hold:

• You are already on Laravel 12 or 13 with PHP 8.3+, using Eloquent API Resources, and a meaningful number of them ship a meta block. On Laravel ≤11 or PHP <8.3 you are looking at 1.1.5 (frozen, no stated support path) or a backport — which changes this from "evaluate" to "fork and own."
• The meta you want to change is cross-cutting — tenant, client type, environment, request context — rather than intrinsic to one resource. If it's intrinsic, additional()/with() on that resource is the right answer and this package is overhead.
• You have more than a handful of resource classes and the duplication cost of touching each one is real.
• You can accept the maintenance: pin a commit, vendor the code into your repo or a private fork, and own it. Zero stars and zero dependents means you are the maintainer in practice. The 2.0 breaking rename is a live demonstration of why.
• You can absorb a namespace move in your fork: toneflix-code/laravel-resource-modifier → toneflix/laravel-resource-modifier, ToneflixCode\ResourceModifier → Toneflix\ResourceModifier, and the published config's import. If you adopt now, adopt the new namespace so you don't pay this twice.

Look elsewhere when:

• You need field-level shaping or hiding — use $hidden, whenLoaded, when(), or an explicit DTO layer. Meta-only interception won't cover it.
• You need full response transformation, headers, status codes, content negotiation, or caching semantics — that's HTTP middleware or a serialization layer (Fractal, spatie/laravel-data, API Platform).
• You have an OpenAPI-first or contract-tested API: response meta should be schema-defined and generated, not mutated by an interception layer that's invisible to your spec.
• Your governance requires maintained dependencies with a security response path. A single-maintainer, zero-adoption package will not survive procurement or a security review at most orgs — and a major-version rename with a hard framework floor is a poor fit for a slow-moving procurement cycle.
• You're not on Laravel API Resources, or you're on a Laravel/PHP version outside the new tested range. The floor is now hard: Laravel 12/13 only, PHP 8.3+.

How to Pitch It (Stakeholders)

Executives: A small, MIT-licensed utility that lets us change the metadata wrapper on our API responses in one place instead of editing dozens of resource classes — useful for client-specific payloads, white-labeling, and deprecating meta fields without a v2 API. Cost is low and the code is small enough to own outright. Two caveats. First, the new 2.0 release raises the floor to Laravel 12/13 and PHP 8.3+, so it only fits squads already on, or committed to, that platform — it is not available to the rest of the fleet. Second, the release is a breaking rename of both the package and its PHP namespace, with no measurable adoption behind it, which confirms our earlier read: vendor it, don't depend on it. Decision requested: allow a one-sprint spike scoped to Laravel 12+ squads only, not a platform commitment.

Engineering: One interception seam for meta on Eloquent API Resources — good for tenant/client-type/request-context concerns that currently get copy-pasted across resources. It is not a serializer, not a field-hiding mechanism, and not visible to your OpenAPI spec, so contract tests need to cover whatever it emits. What changed in 2.0.0 matters for us: package renamed to toneflix/laravel-resource-modifier, namespace to Toneflix\ResourceModifier, require ^8.3|^8.4 PHP and ^12.0|^13.0 Illuminate, dev tooling bumped to Testbench 10/11 and Pest 4, CI matrix now covers only Laravel 12 and 13. Upgrade path is composer remove + composer require :^2.0, then rewrite imports and the published config — trivial if we own the code, annoying if we'd depended on it transitively. Given the adoption profile, plan to fork it into app/Support (or a private package) on day one using the 2.0 namespace, add tests, and pin the Laravel/PHP versions you support. The upside signal is real: a CI matrix against the current framework and a move to a proper vendor org suggests the maintainer is investing, not abandoning. If the spike shows we need more than meta mutation, we've learned cheaply that the real answer is a DTO/serialization layer.