Polymorphic Field Type Laravel Package

Technical Evaluation

What it actually is. Despite the "Laravel/PHP package" framing, this is not a general-purpose Composer library. It is a Streams Platform addon — specifically a field type for anomaly/streams-platform, the addon framework underneath PyroCMS 3.x. It cannot be composer require'd into an arbitrary Laravel application and used on its own; it only has meaning once the Streams addon registry, field type base class, and stream/entry persistence layer are present. That distinction drives almost every conclusion below.

Architecture fit. The field type likely implements the Streams contract (getRelation(), getRules(), getView()/getModifier(), plus persistence hooks) to store a polymorphic reference as a {field}_type / {field}_id column pair and resolve it to the correct stream entry at render time. Architecturally this is the right shape for the problem — it mirrors Eloquent's morphTo. The concern is that the Streams field type API is not stable across major versions, and this package has not tracked any of those changes.

Integration feasibility: low. Signals are unambiguous and mutually reinforcing:

• 0 stars, 0 dependents — no community validation, no downstream testing, no observed production use.
• Last release 2015-08-01 — over a decade stale. This predates Laravel 5.2, let alone 5.5+ or the 6–11 line. Runtime compatibility with current PHP (8.x) is essentially certain to fail: removed helpers, tightened type handling, and each/array_* semantics alone will break it.
• Score 0.18 / opportunity 33.24 — I read the opportunity figure as a low-competition artifact of a dead niche, not genuine unmet demand. There is no competing package because the platform itself has largely faded, not because the problem is valuable and unsolved.

Technical risk. High on every axis: supply chain (unmaintained transitive dependency, no CVE monitoring, no security response path), correctness (no test suite visible, no CI), and data integrity (see polymorphic orphan risk under Operational Impact). There is also no maintainer to escalate to.

Key questions to resolve before any further spend:

1. Is the target application actually on Streams Platform / PyroCMS 3? If no, this package is a non-starter — stop here.
2. What exact anomaly/streams-platform version is pinned, and does a compatible install even resolve today?
3. Are there existing rows already written using this field type? That converts a "reject" into a "data migration" project.
4. What is the real requirement — arbitrary cross-stream references, or just one or two known target types? The latter rarely justifies a polymorphic field type at all.
5. Who owns the fork if we adopt it?

Verdict: Reject for new development. Conditional-accept only for an existing Streams install with live data, and only as a vendored, owned fork — never as an unmodified upstream dependency.

Integration Approach

Stack fit. Two viable worlds, and the answer differs sharply:

• Modern Laravel (5.5+ / 8–11, PHP 8.x): do not integrate. Use native Eloquent morphTo/morphMany with a nullableMorphs() migration, a MorphTo select in your form layer (Filament, Nova, or a custom Livewire/Blade component with a type selector + searchable entry picker), and a Rule::exists() pair validated against the polymorphic type map. Reimplementing this package's behavior natively is a few hundred lines and gives you tests, typing, and a maintainer.
• Existing PyroCMS 3 / Streams Platform: the package is a plausible fit only at the version it was written against. Treat it as source material, not a dependency.

Migration path (if Streams is the target).

1. Confirm the version pin. Inspect composer.json for anomaly/streams-platform constraints and the addon's declared type. Attempt resolution in a throwaway branch; do not merge an attempted install into a shared branch.
2. Vendor and fork. Copy into a private repository, add CI (PHPUnit + a PHP matrix), add static analysis, and take ownership of the version constraint surface. Do not leave a dev-master or 2015 tag floating in a production lockfile.
3. Bump and repair. Update composer.json constraints, fix removed helpers and signatures, verify the field type contract still matches the pinned Streams version (this is the step most likely to require a rewrite of the class rather than a patch).
4. Only then install via the Streams addon installer and register the field type.
5. Backfill/verify the {field}_type / {field}_id columns and confirm all stored type values still map to registered streams.

Compatibility. Assume broken until proven otherwise in a throwaway environment. Test matrix must include the exact PHP version, the exact Streams version, the addon install/upgrade path, and a full create-read-update-delete cycle through the field type — including rendering inside a Streams listing view, which is where polymorphic resolution most often degrades.

Sequencing. Do the requirement interrogation (key questions above) before the fork. If the requirement can be satisfied by a fixed set of two or three known stream references, a plain relation field or a small composite field is lower cost and lower risk than reviving this package. Reserve the polymorphic path for genuinely open-ended reference targets.

Operational Impact

Maintenance. Effectively zero upstream. There will be no bug fixes, no PHP 8.x compatibility work, no dependency updates, and no release when Streams changes. Any adoption is a permanent in-house maintenance commitment, and the cost is front-loaded: the initial port is likely larger than the package itself.

Support. No maintainer, no issue triage, no security response. Internal SLAs must assume "we are the vendor." Budget for at least one engineer with hands-on Streams familiarity — a shrinking skill pool, which is itself a hiring and bus-factor risk.

Scaling. Polymorphic references defeat database-level referential integrity, so no foreign keys. Listing views that render this field must resolve morph targets per row; without explicit eager loading you get classic N+1 behavior that is invisible in development and painful at a few thousand rows. Any Streams query/criteria layer that doesn't understand morph eager loading will need custom handling or a denormalized cache column.

Failure modes to design for:

• Composer resolution failure or silent float to an incompatible tag — mitigate with exact pins and a private fork.
• Fatal errors after a PHP or Streams upgrade — mitigate with a staging pipeline and a smoke test that exercises the field type CRUD path.
• Orphaned references when a target entry or an entire stream is deleted. Polymorphic columns cannot cascade; deletion must be observed (model events or a scheduled reconciliation job) or you accumulate dangling _id values that throw on render.
• Type-map drift when a stream is renamed or a new target type is registered but not allowlisted in the field's settings — results in rows that resolve to nothing.
• Validation bypass — a naive exists rule cannot span tables; a missing custom rule permits references to non-existent entries that only fail at render time, i.e. in production, on read.

Ramp-up. For a team already fluent in Streams addon conventions, roughly a day to orient and a sprint to port, test, and instrument. For a standard Laravel team with no Streams exposure, the onboarding cost of the platform dwarfs the package: weeks, for a capability that is a native Eloquent feature.

Recommendation. Decline adoption as a dependency. If the target stack is Streams and the requirement is real, fork it, own it, test it, and instrument it — and price that work honestly against just writing the relation natively. If the target stack is modern Laravel, this package should not appear in the dependency graph at all.