Relationship Field Type Laravel Package

Product Decisions This Supports

• Content-model normalization. Adding a relationship field is the moment you decide related content lives as a real reference (foreign key) rather than duplicated free-text. That decision affects reporting, cascade behavior, and migration cost later — this package makes the "normalize it" option cheap.
• Adopt vs. build for a lookup control. A related-entry dropdown looks trivial and isn't: option sourcing, empty-state handling, the exists-style validation rule, storage convention, display/label resolution, and permission filtering. This package is the build-vs-buy answer for that slice of work — worth roughly 1–3 engineer-days.
• Roadmap sequencing. It unblocks editorial-linking features (related articles, case study → author, product → category, taxonomy assignment) without touching CMS core or scheduling platform work.
• Ecosystem commitment. Choosing it is a downstream consequence of having chosen the Streams Platform field-type contract. Once multiple streams depend on this field, replacing it becomes a data migration, not a code swap — so this is really a platform-lock-in decision wearing a small package's clothes.
• Use cases it fits: CMS-driven back-office forms, internal tooling on Streams, editorial cross-referencing, catalog taxonomy assignment — anywhere an editor picks one record from a bounded list.

When to Consider This Package

Consider it when:

• You are already on PyroCMS / the Streams Platform and need a foreign-key picker inside stream forms.
• The related set is small and bounded — realistically low hundreds of entries, since a plain dropdown implies loading candidates up front.
• You are comfortable treating a 1-star, zero-dependent, single-maintainer package as vendored source you own (MIT, forkable in an afternoon) rather than a trusted dependency.
• You want a reference implementation of the field-type contract to copy from, even if you don't ship the package itself.

Look elsewhere when:

• You are not on Streams. Use native Eloquent relationships plus a Filament/Nova/Livewire field, or write a ~150-line custom field type.
• You need multi-select, many-to-many with pivot attributes, polymorphic related types, or hierarchical/nested relationships — a single-value dropdown is the wrong primitive.
• The related dataset is large or needs async search, pagination, or permission-scoped option lists.
• You need the relationship exposed and expandable through an API/GraphQL layer.
• Your dependency governance requires tests, CI, release cadence, or a security-response path. One star and zero dependents is a legitimate disqualifier for a strategic dependency; it is not automatically a disqualifier for a tactical utility.

How to Pitch It (Stakeholders)

To executives: A zero-cost, MIT-licensed addon that saves a few days of engineering on "link this record to that record" screens. It is a small utility, not a strategic dependency — approve it as tactical scope, contingent on us already running the Streams Platform. The main risk is not money or integration effort; it is that the package is a thin, near-unadopted artifact from a small ecosystem, so we should not let product capabilities harden around it.

To engineering: The integration surface is small — it implements the Streams field-type contract and renders a select. Plan for the real risks: bus factor of one, no dependents, no visible maintenance. Mitigations are cheap: pin to a commit or vendor the source into our repo, add one smoke test around load/save/validate, cap the size of the related set before we ship it to editors, and keep a documented exit — fork it, or replace it with an in-house field type — so leaving the ecosystem stays a sprint-sized task rather than a migration project.

Framing to use in the decision record: treat this as a reference implementation we adopt, not a library we depend on. That framing keeps the build-vs-buy savings while making the lock-in cost explicit and bounded.