Laravel Dto Morph Cast Laravel Package

Product Decisions This Supports

• Build vs. buy for DTO/domain-boundary plumbing. This package addresses a narrow but recurring Eloquent concern: casting polymorphic (morph-to / morph-type) relationships into typed DTOs instead of loose arrays or untyped models. The decision it informs is whether to invest internal engineering time hand-rolling custom CastsAttributes implementations (and their test coverage) or adopt a maintained package for this single, well-bounded capability.
• API/resource layer architecture. If your roadmap includes tightening the boundary between persistence (Eloquent models) and your application/API surface (DTOs, resources, jobs, events), this package is a candidate to reduce boilerplate and enforce type safety at that seam.
• Incremental hardening, not a feature bet. v1.1.2 is a patch release (1.1.1 → 1.1.2) with no published change detail beyond the compare link. Treat it as maintenance-level (likely bug fixes, dependency or compatibility tweaks) — it does not change the product calculus, introduce features, or signal deprecations. No re-planning required; if you're already adopting, pin/verify via the diff before bumping.
• Use cases to validate against: polymorphic comments/attachments/activity feeds, morph-mapped notification or audit payloads, and any model where a morph relation must hydrate a strongly typed DTO rather than a generic model instance.

When to Consider This Package

Adopt when:

• You already lean on DTOs and want morph relations to hydrate typed objects, not raw models/arrays.
• The boilerplate cost of custom casts (and their tests) outweighs the cost of a small third-party dependency.
• You're on a Laravel version the package's composer.json supports (confirm before committing — the release notes give no compatibility signal).
• You value a small, single-purpose dependency over a broader DTO/mapping framework.

Look elsewhere / defer when:

• You need broad, battle-tested DTO tooling (mapping, validation, nested hydration) — evaluate a fuller DTO package instead.
• Your morph usage is minimal — a few inline custom casts may be simpler than a dependency.
• Governance requires documented changelogs and CVE/upgrade transparency: v1.1.2 ships with no substantive notes, so you'd be trusting the diff rather than a written record. Watch release-note quality and maintainer activity as adoption signals.
• Maturity/community size matters more than fit — verify stars, issue responsiveness, and test coverage before standardizing on it.

How to Pitch It (Stakeholders)

For executives: This is a small, low-risk Laravel utility that makes one specific part of our data layer — polymorphic relationships — produce clean, typed objects instead of loose, error-prone structures. The latest release (v1.1.2) is a routine patch with no new features or breaking changes, so it doesn't affect scope, cost, or timeline. Adopting it is a tactical "buy vs. build" call that saves us writing and maintaining custom plumbing; the main diligence item is confirming release-note transparency and Laravel-version support before we standardize.

For engineering: Single-purpose package for morph-to-DTO casting. v1.1.2 is patch-only with no changelog detail — review the 1.1.1→1.1.2 diff, confirm supported Laravel/PHP versions in composer.json, and pin it. Recommend a short spike on one real morph relation (e.g., comments or attachments) to confirm it fits our DTO conventions before wider rollout.