Model Laravel Package

Technical Evaluation

Architecture fit psx/model is a spec-first DTO/model layer from the PSX ecosystem (apioo). It provides POPO-style model classes, records/collections, and hydration/serialization hooks that are designed to be driven by open data specifications (JSON Schema / OpenAPI-style definitions) rather than by a database ORM. That places it in a different architectural slot than Eloquent: it is a domain/DTO and contract-modeling concern, not persistence. In a Laravel codebase it would sit alongside, not replace, Eloquent — typically in the boundary layer (API request/response payloads, integration contracts, event bodies) where you want typed, schema-validated objects instead of arrays.

For a Laravel team the honest framing is that Laravel already supplies the equivalent slot through a combination of Eloquent casts, FormRequests, API Resources, and — more directly — spatie/laravel-data. psx/model only wins if the organization is genuinely spec-driven (a published OpenAPI/JSON Schema contract is the source of truth and you want generated, typed models that stay in lockstep with it). Absent that, the architecture fit is poor because it introduces a second modeling paradigm next to Eloquent with no Laravel-native on-ramp.

Integration feasibility Composer-installable and PSR-4 autoloadable, Apache-2.0, so legal/procurement friction is minimal. The real friction is wiring: there is no Laravel service provider, no facade, no config publish, and the package's design assumptions lean on the PSX runtime (PSR-11 container, psx/data-style hydration, psx/schema for spec parsing). We would be writing our own bridge — a service provider, container bindings, and an adapter that maps Eloquent models to psx/model objects and back. That is a day or two of glue, not a blocker, but it is glue we own forever.

Technical risk High, and concentrated in supply-chain rather than code quality. Nine stars and zero dependents means effectively no production validation outside the maintainer's own projects. Bus factor is one. Documentation is thin and oriented toward the PSX framework, so most integration knowledge will come from reading source. The transitive dependency on PSX-family packages (psx/data, psx/schema) is the sharpest edge: those carry their own release cadence, PHP version constraints, and potential conflicts with Laravel's dependency graph. Apache-2.0 is clean; the attack surface is small since this is pure PHP data modeling, but there is no evidence of third-party security review.

Key questions

• Which specification dialects are supported at the version we would pin — JSON Schema draft, OpenAPI 3.0/3.1 — and how faithful is the generation for nested/oneOf/anyOf shapes?
• Does it function standalone, or does it hard-require the PSX container and psx/schema at runtime?
• PHP version support and the package's upgrade history across PHP 8.x — how often have majors broken?
• What is the maintainer's commit cadence over the last 12–24 months, and are issues answered?
• Can we consume only the model interface/hydration surface and skip the spec-generation half, reducing the dependency surface?
• What does the equivalent cost look like in spatie/laravel-data or hand-written readonly DTOs with cebe/php-openapi for validation?

Integration Approach

Stack fit Assumes Laravel 10/11 on PHP 8.1+. Fit is conditional: strong if the team maintains an OpenAPI contract as a first-class artifact and wants generated PHP models; weak if the goal is simply "less array juggling," where spatie/laravel-data is idiomatic, Laravel-aware, actively maintained, and has a far larger support base. The TPM recommendation should be to treat psx/model as a candidate for a narrow, contract-bound slice, never as a foundational dependency.

Migration path Do not migrate anything onto it. Introduce it greenfield behind an anti-corruption layer: define our own PayloadModel interface in the app, implement it with psx/model classes, and bind via the container. That preserves optionality — swapping the implementation for laravel-data becomes a container binding change plus regenerated classes, not a rewrite. If we later adopt its generation pipeline, generated classes live in a dedicated namespace and are treated as build artifacts (regenerated, not hand-edited), which mirrors how we already handle compiled assets.

Compatibility Expect to author a small service provider and a hydration adapter (Eloquent model → psx model → array/JSON). Watch for: (a) container assumptions that conflict with Laravel's PSR-11 bindings, (b) transitive dependency version pins colliding with Laravel's illuminate/* constraints, (c) serialization semantics differing from Laravel's JsonResource output, which would surface as contract drift in API responses. Verify all three in a composer-level spike before any code is written.

Sequencing

1. Spike (3–5 days): install, generate models from one real OpenAPI fragment, measure output quality and hydration correctness on nested payloads.
2. Comparative bake-off: same fragment through spatie/laravel-data and through hand-written readonly DTOs; score on generation fidelity, ergonomics, dependency weight, and maintenance outlook.
3. Adapter build: interface + service provider + mapping layer, if and only if the spike beats the alternatives.
4. Pilot: one outbound integration (low blast radius, no persistence coupling).
5. Decision gate: adopt into a second context only if the pilot holds; otherwise retire the dependency and keep the interface.

Operational Impact

Maintenance The dominant cost is not runtime but ownership. With one maintainer and no downstream dependents, we should plan on forking the package into a vendored path or maintaining a private mirror within 12–18 months, and budget accordingly. Generated model classes must be regenerable from a pinned spec version — treat the spec, the generator version, and the generated output as a single versioned unit so upgrades are atomic and reviewable.

Support No meaningful community: no Stack Overflow corpus, no Laravel-adjacent blog coverage, no Discord. Support is GitHub issues answered by one person, on their schedule. Internal runbook and a named owner are mandatory; without them the package becomes tribal knowledge and dies with the developer who integrated it. Contrast this with laravel-data, which has a large support surface and reduces on-call ambiguity.

Scaling Runtime scaling is a non-issue — this is a CPU-bound hydration layer, and object mapping cost is linear in payload size and negligible relative to network and database I/O. The bottleneck to plan for is cognitive scaling: a second modeling paradigm alongside Eloquent raises onboarding cost and invites inconsistency (some endpoints returning Eloquent resources, some returning psx models). Constrain it with a written architectural rule about which layer owns which payload type.

Failure modes

• Abandonment: no commits for a release cycle, then an incompatibility with a new PHP or Laravel major, leaving us stranded.
• Silent hydration drift: spec and generated models desynchronize; payloads hydrate with missing or defaulted fields and fail downstream rather than at the boundary. Mitigate with schema validation at ingress, not just typed objects.
• Transitive conflict: a psx/* dependency bump forces an illuminate/* version we cannot move to, freezing our Laravel upgrade path.
• Serialization divergence: psx output differs subtly from JsonResource, breaking a consumer's contract after an upgrade.
• Bus factor: the sole maintainer becomes unavailable; no security patching path.

Ramp-up Moderate to high for a small package. There is little to read; most learning is source-diving, plus PSX-specific concepts (spec-driven model generation, PSX hydration semantics) that no one on the team knows. Estimate one to two developer-weeks before a mid-level engineer is productive, versus roughly two to three days for laravel-data. That delta is the recurring tax on every future hire, and it should be weighed explicitly against whatever contract-generation value the spec-driven workflow delivers.

Verdict for the TPM record: given 9 stars, 0 dependents, a score of 0.105, and single-maintainer risk, psx/model is not approved as a core dependency. It is worth a bounded spike as a build-time model generator only if the organization already treats OpenAPI as the source of truth; otherwise the recommendation is spatie/laravel-data for DTOs plus cebe/php-openapi for contract validation, which delivers 80% of the value with a fraction of the operational risk.