Transformers Laravel Package

Product Decisions This Supports

• API response contract architecture — whether to introduce a dedicated transformation layer between Eloquent models and JSON output, so that database schema changes never silently break the public response shape. This is the core decision the package embodies.
• Public/partner API surface design — standardized serialization, relationship includes, sparse fieldsets, and pagination metadata are contract-level commitments. Deciding where those live (controllers vs. resources vs. transformers) is a roadmap-shaping choice that is expensive to reverse after external consumers integrate.
• API versioning strategy — a transformer layer gives you a seam to freeze a v1 representation while the underlying model and business logic evolve. Directly supports whether v2 is a rewrite or a parallel set of transformers.
• Multi-client representation — web, mobile, and internal admin consumers often need different shapes of the same entity. Transformers make "same data, different payload" a configuration concern rather than duplication in controllers.
• Build vs. buy vs. adopt-the-pattern — this package is the "thin wrapper on League/Fractal" option in that trade-off. The realistic comparison set is Laravel's first-party API Resources (zero additional dependency), Spatie's laravel-fractal (maintained Fractal integration), or hand-rolled transformers (full control, no supply-chain surface).
• Engineering standardization — if the org already has Fractal-based services, this repo is a compact worked example of transformer auto-resolution and conventions worth codifying in an internal style guide, independent of the package itself.

When to Consider This Package

Consider it only as reference material or a fork source, not as a runtime dependency. The signals are decisive: archived, 1 star, 0 dependents, last release August 2024, and a low opportunity score. Archival means no upstream fixes, no Laravel major-version compatibility work, and no CVE response — every future upgrade cost lands on your team.

Reasonable cases to open the repo:

• You are already committed to League/Fractal and want to read a small, MIT-licensed implementation of transformer resolution conventions before writing your own.
• You are scoping a "buy vs. build" comparison and need a concrete example of what a thin Fractal-on-Laravel wrapper actually contains (usually a few hundred lines — which is itself the finding).
• You are vendoring/pinning the code into your own namespace with an explicit owner and upgrade plan.

Look elsewhere when:

• Greenfield project → use Laravel API Resources. First-party, no extra dependency, no archival risk, documented upgrade path.
• You want Fractal specifically, but maintained → Spatie's laravel-fractal has real adoption and active maintenance.
• Your org requires supported dependencies (SBOM, CVE monitoring, vendor SLAs, LTS guarantees) → archived packages are disqualifying on procurement/compliance grounds regardless of code quality.
• Non-Laravel or non-Fractal architecture → the wrapper's value is almost entirely framework glue; there is nothing left to use.

How to Pitch It (Stakeholders)

To executives: The idea is sound and the implementation is not the asset. This package is a thin, archived wrapper around an established open-source serialization library, with effectively zero adoption. Adopting it as a dependency would introduce unmaintained code into our stack in exchange for saving perhaps a few days of setup. Recommendation: adopt the pattern — a dedicated transformation layer between our data models and our API responses — using framework-native tooling we already support. That gets us the same contract stability and API-versioning benefits with no new supply-chain risk and no orphaned dependency to carry through the next Laravel upgrade.

To engineering: Treat this repo as a design reference, not a dependency. If we want a transformation layer, we get it from Laravel API Resources at no incremental cost. If the team has a specific reason to prefer Fractal's serializer model, use the maintained laravel-fractal integration instead. The one thing worth extracting from this package is its conventions for transformer resolution — read it, agree on ours, write it down. Net effect: same architectural outcome, fewer dependencies, clear ownership, and an upgrade path that survives the next framework major version.