Model Factory Laravel Package

Technical Evaluation

Architecture fit. The package implements a presentation-mapping layer: a factory registry resolves a domain object to a view model/DTO via a supports() predicate, factories can be aggregated into a collection, and models compose nested models lazily. That is a legitimate and architecturally clean position — it sits between the domain and the serializer, so it is transport-agnostic (JSON, JSON:API, XML, Inertia props, gRPC payloads) and decoupled from Eloquent. It fits well in hexagonal/DDD-flavored codebases where the API contract must not leak ActiveRecord semantics. It is not a drop-in competitor to Laravel API Resources or spatie/laravel-data; it is a lower-level primitive that those tools partially subsume. For a team already fighting toArray() leakage from models, the pattern is genuinely useful. For a team on stock Eloquent, it adds a layer with no compensating payoff.

Integration feasibility. Framework-agnostic PSR-4 PHP, MIT licensed, Composer-installable — container wiring in Laravel is a one-file service provider: bind the factory collection as a singleton, inject it into controllers or a response macro. No framework lock-in, no runtime extension requirements, no DB coupling. Integration effort is genuinely small; the risk is not "can we wire it," it is "what are we wiring in."

Technical risk. Assess this as an unmaintained code sample rather than a dependency:

The opportunity: 25.07 and score: 0.01 signals confirm there is no ecosystem, no battle-testing, and no downstream validation.

Key questions.

1. What is the exact supports() contract — instanceof, class-string equality, interfaces, or duck typing? Is matching order-sensitive?
2. What happens on no-match: typed exception, null, or passthrough of the raw object?
3. Does the factory collection detect ambiguous matches, or silently take the first?
4. How is recursion handled — circular domain graphs, self-referencing parents, bidirectional relations? Is there a depth guard?
5. Are lazily-built nested models closures on the object? If so, are the resulting models serializable (serialize(), queue payloads, Cache::put)?
6. What PHP versions are actually declared in composer.json, and does the code emit deprecations on 8.2/8.3?
7. Is there a test suite and CI config in the repo, and does it run green on a current PHP?
8. How are paginators, Laravel Collections, and CursorPaginator handled — first-class or manual wrapping?
9. Does the model expose an explicit toArray()/JsonSerializable contract, or is output shape implicit in property visibility?
10. Any known integration with JsonResource, validation, or Laravel's Responsable?

Integration Approach

Stack fit. Best fit: PHP 8.1+, Laravel 9/10/11, domain layer that is not Eloquent-shaped (value objects, aggregates, read models). Poor fit: Laravel 8 or earlier is fine technically but puts you on an EOL framework; heavy Inertia/Livewire apps where props are already arrays and the mapping layer is ceremony. Verify PHP constraint compatibility before anything else — a ^7.4 || ^8.0 constraint will block install on a Laravel 11 app and force a --ignore-platform-reqs fork on day one.

Migration path. Do not adopt the package as a dependency; adopt the pattern behind an internal seam. Concretely: (a) vendor or fork the source into app/Support/Presentation or a private internal/model-factory package so you own the code; (b) define your own ViewModelFactory interface and ViewModelRegistry in the app, with the fork as one implementation; (c) migrate endpoint-by-endpoint, starting with a read-only, low-traffic API surface that already has golden-file response fixtures; (d) keep the existing JsonResource in place behind a feature flag for a parallel-run window and diff outputs in staging.

Compatibility checklist. Eloquent models and eager-loaded relations, LengthAwarePaginator/CursorPaginator, Carbon/CarbonImmutable, backed enums (8.1), readonly DTO properties (8.2), nullable and uninitialized typed properties, JsonSerializable nesting, and Arrayable interop. Each of these is a plausible gap in a 2021 library and each is a one-line failure in production.

Sequencing. Week 1: fork audit + PHP 8.3 compatibility spike + test-suite triage. Week 2: internal interfaces, container bindings, one pilot endpoint behind a flag. Week 3–4: expand to the remaining read paths; codify a "no factory found" exception with alerting. Only after the seam exists should you evaluate whether to keep the fork or replace it with spatie/laravel-data, which gives you validation, casting, and an active maintainer for roughly the same conceptual slot.

Operational Impact

Maintenance. You are acquiring code, not a dependency. Budget an owner and roughly 2–5 engineer-days per year for PHP-version upkeep, plus the initial fork hardening. Upstream will not merge your patches; treat the fork as first-party and delete the composer require line entirely so no one accidentally upgrades to a 2021 tag. Pin the license header (MIT permits this; preserve the copyright notice).

Support. No community, no Discord, no Stack Overflow corpus, no CVE feed. Documentation is a README. This is acceptable only if the fork is small enough (~a few hundred lines) that any engineer can read it end-to-end — verify that before committing.

Scaling. Mapping itself is CPU-cheap and linear; it will not be your bottleneck. The scaling risk is structural: lazy nested resolution can turn a single serialization pass into N+1 queries if nested models touch the ORM. Mitigate with eager-load contracts declared at the controller boundary, a query-count assertion in tests (Laravel's DB::listen or laravel-query-detector), and a hard rule that view models never issue queries at access time. Memory scales with the full materialized response tree — relevant for large collection exports, where streaming or chunked responses may be preferable to building the whole view-model graph.

Failure modes. Rank and instrument each: (1) unsupported class at runtime — must throw a typed, logged exception rather than emit a raw domain object into the response; (2) infinite recursion on circular graphs — needs a depth cap and a cycle detector, or it becomes a stack-overflow 500; (3) lazy access after serialization boundary — queries fired post-commit or post-response; (4) non-serializable view models in queued jobs or cache; (5) silent shape drift when a domain object gains a property and the factory ignores it — the contract is implicit, so pair with response-schema snapshot tests; (6) PHP deprecation noise on 8.2+ surfacing as log spam before it surfaces as errors. Add a metric for "factory miss" and alert on nonzero.

Ramp-up. Small API surface → low learning curve for the happy path, maybe half a day. The cost is concentrated in undocumented edge cases: matching order, recursion, and laziness semantics. Write the internal README yourself during the pilot; that document, not the fork, is what makes the layer safe to own.

Recommendation. Adopt the pattern, fork the implementation, cap the investment. The package is a credible reference design at 2 stars with no dependents and a 2021 release date — it is not a dependency you install and forget. If the pilot endpoint does not measurably improve contract clarity over the existing resources within two weeks, stop and standardize on spatie/laravel-data instead.