Polymorphic Field Type Laravel Package

Product Decisions This Supports

• Build vs. buy for content modeling in Streams/PyroCMS-based products. This package is a single-purpose field type that lets a Streams field point at more than one model type at runtime (a "polymorphic" relation as a CMS field). It informs only one narrow decision: whether to source that capability off the shelf or implement it in-house. Given 0 stars, 0 dependents, and a last release of 2015-08-01, the honest answer it supports is build or don't build — not buy.
• Roadmap scoping for a CMS-powered product. If your roadmap includes flexible content schemas (e.g., "related content" that can be an Article, a Product, or a Page), this package is evidence that such a requirement exists in the Streams ecosystem but was never productized. Treat it as a requirements artifact, not a dependency: a 30-minute read of its source tells you what a polymorphic field type must do in Streams, which is directly reusable in a spec.
• Prioritization of platform investment. A near-zero score (0.18) with zero dependents is a strong signal that the Streams addon ecosystem is thin. If your product depends on Streams addons for differentiation, budget for first-party field types rather than assuming community supply. Conversely, if you're evaluating Streams/PyroCMS as a platform at all, absence of maintained addons is a portfolio-level risk to weigh.
• Vendor risk triage. Use this as a worked example in your dependency policy: MIT-licensed, PHP-5-era, unmaintained since 2015, no issue/PR traffic. Any decision to adopt should route through a "fork-and-own" cost estimate, which is typically 1–3 engineer-days for a field type of this size plus ongoing compatibility testing against Laravel/PHP upgrades.
• Make-vs-migrate calls on legacy installs. For teams already running an old PyroCMS/Streams site that uses this package, the decision it supports is "contain, don't extend" — freeze the feature, avoid new schema that depends on it, and plan migration before the next PHP minor.

When to Consider This Package

Consider it only if all of the following hold:

• You are already on the Streams Platform (PyroCMS 3.x-era) and your field type registration, migrations, and admin UI live in that ecosystem — the package is meaningless outside it.
• Your runtime is pinned to the PHP/Laravel versions this was built against, and you have no near-term upgrade on the roadmap.
• The requirement is genuinely polymorphic (one field, many possible model types) and you have no appetite to write the field type yourself.
• You are willing to fork and own it: pin the commit, vendor it, and accept that you are the maintainer of record.

Look elsewhere — or build — if any of the following apply:

• Greenfield project, or anything on a currently supported Laravel. Native morphTo/morphMany Eloquent relations plus a small custom field type will cover this in roughly the time it takes to audit a 2015 codebase, with no abandonware risk.
• No Streams dependency. You are paying a full CMS-platform tax for one relation type. A standalone polymorphic relation, a tagging/association package, or a JSON column with a type discriminator is the lighter buy.
• Maintenance or security posture matters (it should). Last release 2015-08-01, zero dependents, zero stars means no upstream security response, no compatibility fixes, and no community debugging. There is no support surface to lean on.
• You need the adjacent capability instead. If the real need is "relate entries to other entries within Streams," a relationship-style field type is the closer fit; if the real need is cross-model references in a modern app, Eloquent's polymorphic relations are the answer, not a CMS field type.
• You're evaluating for a portfolio or long-lived product. Zero dependents is the key number: nobody else has validated this in production, so you'd be the first, on a decade-old base.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a free, MIT-licensed add-on that adds a single content-modeling capability — a field that can point at multiple kinds of content — to the Streams/PyroCMS platform. It is not a strategic dependency. It has no measurable adoption (0 stars, 0 dependents), no release since August 2015, and no maintainer activity, so it carries abandonware and upgrade risk without offsetting cost savings. Recommendation: do not adopt as a dependency. If the capability is on our roadmap, treat this package as a reference design and budget a small, bounded build (days, not weeks) as a first-party field type we control. The only scenario where it earns a place is an existing legacy Streams install where we contain and freeze rather than extend.

For engineering (the short version): Narrow scope, MIT, ~one field type's worth of code that registers a polymorphic relation inside Streams' field-type contract. It's structurally simple but frozen in the PHP 5 / early Laravel era, with no test signal and no upstream. Two viable paths: (1) fork, pin, vendor, and own it — accept compatibility testing on every framework bump; or (2) read it for the Streams field-type pattern and reimplement against current Eloquent morphTo in a day or two. We recommend (2) unless a legacy install forces (1). Either way, don't let it become an unpinned transitive dependency.

One-line ask: Approve a timeboxed spike to spec a first-party polymorphic field type; do not add this package to the dependency tree.