User Field Type Laravel Package

Product Decisions This Supports

• Content modeling / data architecture: This package answers a single specific question — "how do we attach a user reference to a piece of content?" If our roadmap includes author attribution, assignees, approvers, reviewers, or owners on CMS entries, this is the field-type-level answer for the Streams Platform.
• Build vs. buy (buy vs. copy): It is a thin, MIT-licensed field type. The real decision is not "buy" but "adopt as-is, fork, or write in-house." A PM should frame it as a reference implementation — reading it tells engineering exactly what a custom user-picker field type costs to build (small), which is useful for scoping.
• Feature increments on an existing PyroCMS/Streams install: If we are already running anomaly/streams-platform, this is a same-day addition — one field type registration — versus a bespoke module. That is a cheap roadmap unlock for workflow features (assign, approve, escalate).
• Ecosystem strategy: Adopting this signals we are standardizing on the Anomaly Labs addon ecosystem (Streams platform). That is a platform bet, not a component bet, and should be made deliberately at the architecture level.
• Maintenance ownership planning: With zero stars and zero dependents, adoption is effectively an internal fork decision. The PM decision this supports is "who on the team owns this code if it breaks," not "should we depend on a vendor."

When to Consider This Package

Consider it when all of the following hold:

• We are already committed to anomaly/streams-platform / PyroCMS as the content backbone. Outside that ecosystem this package has no value — it is not a general-purpose Laravel package and will not work in a vanilla Laravel app.
• The requirement is a single-select user dropdown as a stream field. If we need multi-select, role- or permission-filtered lists, tenant scoping, searchable/async lookup, or "current user" defaults, verify the package supports them (likely not) before adopting.
• We are comfortable treating the code as ours: MIT license permits forking and vendoring, and the adoption risk is low in absolute terms because the surface area is tiny.
• We need a baseline or reference for building a richer field type later.

Look elsewhere when:

• We are not on Streams/PyroCMS. Use native Eloquent relations (belongsTo(User::class)) with a standard select input instead.
• We need an actively maintained, community-vetted dependency. Zero stars and zero dependents means no external validation and no support channel — no issue triage, no security response, no upgrade path.
• We need this field to participate in permissions, notifications, or workflow engines. Field types only store and render values; the surrounding logic must be built and owned by us.
• We are on a supported-versions policy. Pin the version and confirm compatibility with our Laravel/PHP versions ourselves; there is no version matrix to lean on.

How to Pitch It (Stakeholders)

For executives (30 seconds): This is a small, free (MIT) add-on that lets our content system reference a user — useful for "author," "assignee," or "approver" fields. It is only relevant if we are already on the Streams/PyroCMS platform. The financial risk is minimal because the code is ours to fork, but there is no community behind it, so we should treat it as internal code we maintain rather than a vendor product. Recommend: adopt only as part of a broader platform decision, not on its own merits.

For engineering: It is a thin Streams field type — a dropdown that selects a user record. Low complexity, low integration cost, but effectively unmaintained (0 stars, 0 dependents, no release cadence to rely on). Recommend we vendor/fork it, pin the commit, read it before depending on it, and confirm Laravel/PHP compatibility in our environment. If the requirement grows past single-select, we own that work.

Recommendation: Conditional adopt. Only stack it onto an existing Streams install and only for a genuinely simple single-user picker. Otherwise build a native relation on our own user model — the cost is comparable and the ownership story is clearer.