Improved Polymorphic Eloquent Builder Laravel Package

Product Decisions This Supports

• Feature feasibility for polymorphic domains. Any feature where a single entity attaches to multiple parent types — activity feeds, comments, attachments, notifications, tagging, audit trails, "recently viewed" — depends on querying and filtering polymorphic relations efficiently. This package exists to close gaps in how Laravel's morphTo side of a relation can be constrained, eager-loaded, and filtered.
• Build vs. buy vs. use-the-framework. The core PM decision this informs is not "which package" but "do we need third-party code for this at all?" Since Laravel 5.8, the framework ships native morph-aware query methods (whereHasMorph, whereDoesntHaveMorph), which is functionally the territory a 2018 package like this was filling. The default answer should be use the framework; adoption requires a specific, documented gap.
• Upgrade and tech-debt prioritization. The existence of this dependency is a signal about platform age. If it appears in a dependency audit, it tells you the application is likely pinned to an older Laravel/PHP combination and should be scheduled for a framework upgrade rather than extended.
• Legacy modernization sequencing. Where the package is already in production, this frames a roadmap item: replace the dependency with native builder methods as part of the next Laravel upgrade, so the risk is retired rather than carried forward.
• Licensing and distribution posture. LGPL-3.0 is unusual for a PHP library and introduces obligations that matter if the product is distributed (on-prem, white-label, SDK, appliance) rather than operated as a service. This is a legal/product decision, not just an engineering one.

When to Consider This Package

Consider only when all of the following hold:

• The application is pinned to a Laravel version predating native morph query support (pre-5.8) and a framework upgrade is genuinely blocked in the near term.
• You have a concrete, currently painful requirement — filtering or eager-loading across polymorphic relations — that cannot be expressed with the existing builder without material workarounds.
• The affected code path is internal and non-critical, and the team accepts ownership of a pinned, unmaintained dependency.
• Legal has reviewed LGPL-3.0 obligations against your distribution model.

Look elsewhere when any of the following is true (the common case):

• You are on Laravel 5.8 or later. Use whereHasMorph / whereDoesntHaveMorph and morph-aware eager loading natively. No package required.
• Maintenance signals matter. Last release January 2018, ~11 stars, effectively a single-maintainer project with no meaningful community. No PHP 8 / modern Laravel compatibility work, no security response, no bug-fix path. Treat it as unmaintained code you would be adopting and supporting.
• You need a durable dependency. For polymorphic relationship ergonomics on modern Laravel, the maintained options are the framework itself or actively developed packages in the broader Eloquent-relationship ecosystem — not this one.
• The requirement is narrow. A short custom scope, query scope, or trait on your own models usually covers a single filtering need with less surface area than a dependency, and it lives inside your test suite.
• You are deciding for a new build. Adding a 2018 package to greenfield work is a net negative: it buys functionality the framework already provides and imports maintenance risk.

How to Pitch It (Stakeholders)

For executives: This package solves a real but narrow problem — making polymorphic database relationships easier to query in Laravel. The important finding is that the framework has since absorbed this capability, and the package itself has had no release since early 2018 with negligible adoption. Recommendation: do not adopt. The cost is not the code, it is the ownership — an unmaintained dependency in a core data-access path, plus non-standard LGPL licensing to review. There is no capability here worth paying that price for.

For engineering: The value this package offered was constraining and eager-loading the morph side of a morphTo relation, which native Laravel now handles via whereHasMorph/whereDoesntHaveMorph and morph-aware eager loading. For any code that would have used it, implement the equivalent with native builder methods plus a small local scope or trait, covered by tests. Where the package already exists in a codebase, treat it as an upgrade-blocker marker: replace usages as part of the next Laravel upgrade and remove the dependency, rather than patching around it. If a legacy constraint forces temporary retention, time-box it with an explicit exit criterion tied to the framework upgrade.