Laravel Eloquent Morph To One Laravel Package

Product Decisions This Supports

• Feature scoping for polymorphic one-to-one relationships. This package adds a morphToOne relationship type to Eloquent — a first-class way to declare "this model has exactly one polymorphic counterpart" without hand-rolling query constraints or collapsing a morphMany into an accessor. That directly affects how we model shared attachments (comments, media, addresses, audit targets) in domain layers, and whether we accept a non-native relationship type in our schema conventions.
• Framework upgrade planning (the actual trigger for this release). 2.6.0 is a compatibility release: Laravel 13.x and PHP 8.5 support, no breaking changes and no new API surface. If Laravel 13 is on the roadmap, this removes a blocker and lets us schedule the upgrade without hunting for a replacement dependency. If we stay on 11/12 for the next two quarters, the upgrade is optional and can ride along with routine maintenance.
• Build vs. buy for a thin abstraction. The functionality is small enough to reimplement internally, but the cost isn't the initial code — it's the long tail: eager loading (with), whereHasMorph interaction, morph-map resolution, and existence queries. Buying keeps that edge-case maintenance off our engineers; building means owning it forever. Default recommendation: buy, unless our dependency policy restricts single-maintainer packages.
• Vendor risk inventory. The 2.6.0 release is a positive maintenance signal (the maintainer is tracking framework releases promptly), but it doesn't change the underlying profile: small package, single primary maintainer, low release cadence. That's acceptable for a dev-only convenience dependency — it never touches runtime infrastructure — but it should be logged in our dependency register with a named owner and a "replace or fork" fallback.
• Adoption scope decision. This is an authoring-time ergonomics improvement, not a user-facing capability. It doesn't unlock features we can't ship otherwise; it makes model code cleaner and less error-prone. That makes it a low-stakes "yes" for teams already comfortable with advanced Eloquent, and a skip for teams that prefer to stay strictly on framework-native relationship types.

When to Consider This Package

Consider it when:

• You have (or expect) one-to-one polymorphic relationships in your domain and want them expressed as a declarative relationship rather than a scoped query or a morphMany + ->first() accessor.
• You rely on eager loading and relationship query builders (with, has, whereHas) for those associations and don't want to hand-write the constraints each time.
• You're planning or currently executing a Laravel 13 / PHP 8.5 upgrade and need dependencies that are already declared compatible — 2.6.0 is exactly that signal.
• Your team is comfortable with advanced Eloquent and treats model-layer readability as a real maintenance cost worth optimizing.
• It stays a dev/application-layer convenience with no migration, config, or service-provider footprint — low lock-in, easy to remove.

Look elsewhere (or build in-house) when:

• Your dependency policy restricts small, single-maintainer packages, or requires an internal fork / vendor mirror before adoption.
• The relationship could be modeled with native morphOne or morphTo without awkwardness — if native works, native wins; no reason to add a dependency for parity.
• You need guaranteed long-term support contracts, security SLAs, or a funded maintainer — this package offers none of those.
• You're not upgrading to Laravel 13 or PHP 8.5 in the near term — there's no functional reason to move from 2.5.0 to 2.6.0, so treat it as a routine bump rather than an initiative.

How to Pitch It (Stakeholders)

For executives (30 seconds): A small, free open-source library we use for one specific pattern in our data model — models that point to exactly one polymorphic related record. Version 2.6.0 is a compatibility update so it keeps working on the newest Laravel and PHP releases. No breaking changes, no new behaviour, no cost, and no user-visible impact. The decision it informs is whether we standardize on this pattern in our models, and it's a low-risk yes: the package is easy to remove and doesn't touch our infrastructure. The one caveat worth noting is that it's maintained by a single developer, so we treat it as a convenience dependency, not a critical one, and we have a fallback if it's ever abandoned.

For engineering: 2.6.0 adds Laravel 13.x and PHP 8.5 support with no API changes — a pure compatibility bump, so upgrading is safe and non-urgent unless we're moving to Laravel 13. Value proposition is ergonomic: a declarative one-to-one polymorphic relationship with correct eager-loading and query-builder behaviour, instead of a morphMany + accessor or a hand-scoped query. It's a small, single-maintainer package, so pin the minor version, cover our usages with a relationship test, and record it in the dependency inventory with an owner and a replace-or-fork path. Adoption should be a shared convention decision, not a per-team choice — mixing native morphOne and morphToOne for the same conceptual pattern will confuse new joiners.