Multiple Field Type Laravel Package

Product Decisions This Supports

• Content modeling for repeatable fields: This addon gives PyroCMS/Streams-based products a "multiple" field type — one control that stores N instances of another field type (multiple text lines, image lists, address blocks, spec tables). It directly supports decisions like "do we ship repeatable content blocks in v1, or defer to a page builder?"
• Build vs. buy for admin UI primitives: Because it's MIT and self-contained, it's a cheap candidate to vendor into your codebase rather than spend 1–2 sprint weeks building a repeatable-field control from scratch — if you are already committed to the Streams Platform.
• Roadmap scoping for content-heavy features: Useful as an existence proof when estimating features such as multi-image galleries, multi-author bylines, ingredient lists, FAQ sets, or per-locale variants. It answers "what's the smallest data model that supports this?" without a second CMS.
• Go/no-go on ecosystem lock-in: Evaluating this package is really a decision about whether PyroCMS/Streams is your content backbone. Its value is entirely derived from that platform choice, so treat it as a forcing function for that larger architectural call.
• Risk acceptance for a low-signal dependency: 0 stars, 0 dependents, and a 0.48 score mean it is effectively unmaintained. A PM decision here is not "adopt" but "adopt as internal code we own" — which sets the maintenance budget and the fork/ownership expectation before engineering starts.
• Not a differentiator: Nothing here is defensible IP. It should never appear on a customer-facing roadmap or a competitive positioning slide; it's plumbing.

When to Consider This Package

Adopt (as a vendored fork) when all of the following hold:

• You are already running PyroCMS 3.x / the Streams Platform, and the alternative is a custom field type plus custom admin JS.
• You need repeatable instances of an existing field type and do not need a full drag-and-drop block/page builder.
• You accept ownership: pin a commit, fork to your org, add tests and a migration path, and assign a named maintainer. Budget ongoing upkeep — assume upstream will not help.
• The content model is stable — repeatable fields tend to leak into templates, exports, and API contracts, so churn here is expensive.
• MIT licensing is compatible with your distribution model (it is, but confirm attribution obligations in your notices file).

Look elsewhere when:

• You are not on Streams/PyroCMS — there is no meaningful path to reuse this in vanilla Laravel, Nova, or Filament.
• You want a maintained dependency: Laravel Nova's Repeater/KeyValue, Filament's Repeater/Builder, Statamic's Replicator, or Craft's Matrix are better-supported equivalents and represent the real alternatives in a build-vs-buy comparison.
• Your need is simple and bounded — a JSON column plus a cast, or a related Eloquent model with an ordered pivot, is often less total cost than integrating and owning a platform addon.
• You require SLAs, security responsiveness, or vendor support — none exist here. Zero dependents also means zero community bug-finding; you are the first line of defense.
• Long-term platform risk is unacceptable: PyroCMS/Streams' ecosystem momentum is thin, and pinning your content layer to it amplifies that risk.

How to Pitch It (Stakeholders)

To executives: This is a small, free (MIT) addon that adds repeatable fields to our CMS admin — think "add another image" or "add another FAQ row" without engineering work per feature. The strategic point is not the package; it's that it only works if we standardize on PyroCMS's Streams platform. The package itself is low-risk in cost and high-risk in support: it has no meaningful community (no stars, no downstream users, no active maintainer), so if we use it, we own it. Recommendation: treat it as a candidate to vendor and maintain internally, not a dependency we rely on someone else to keep alive — and use it as the trigger to decide, once, whether Streams is our content backbone. If we're not on Streams, this is a non-option and Nova/Filament/Statamic repeaters are the real comparison.

To engineering: It's a Streams field type that wraps another field type and stores multiple values with ordering. Cheap to integrate, trivial to fork (MIT), but unmaintained — expect to pin a commit, add tests, and own migrations. If we adopt, we fork on day one and never depend on upstream. If you'd rather not own it, the honest alternative is a JSON column plus a cast, or a related model with an order column — both are more work up front and less mystery later. Give me a one-week spike estimate with a fork-and-test task included so we can compare it against the in-house option on total cost of ownership, not just integration time.