Repeater Field Type Laravel Package

Product Decisions This Supports

• Content modeling: normalize vs. denormalize. The core decision this package informs is whether a variable-length set of sub-fields (bullet lists, team members, FAQ items, feature cards, CTA rows) should live as a child stream/table or as a single serialized field on the parent record. This addon makes the denormalized option cheap, which is usually the right call for presentation-only content that editors own.
• Editorial autonomy / roadmap velocity. Repeating blocks are the single most common reason marketing asks engineering for "just one more field." Adopting this lets content shape change without a migration, a deploy, or a ticket — a measurable reduction in content-ops cycle time.
• Build vs. buy (specifically: buy). If the product already runs on PyroCMS/Streams, this is a drop-in field type under a permissive MIT license. Building an equivalent admin UI, validation layer, and storage contract is days of work for a commodity capability — poor use of engineering capacity.
• Feature scoping for CMS-driven pages. It unlocks landing-page and template-driven features (modular page sections, repeating promo tiles) without committing to a page-builder. Useful as a "good enough" step before deciding whether a full block-based editor is on the roadmap.
• Platform lock-in assessment. Choosing this is implicitly a decision to stay on the Streams field-type ecosystem. Worth surfacing explicitly to architecture, because the cost of leaving later is re-modeling every stream that uses repeaters.

When to Consider This Package

Adopt when:

• You are already on PyroCMS / the Anomaly Streams platform and need a repeatable group of fields inside a single stream entry.
• The repeated data is presentational and consumed as a whole (render the block, don't query individual rows).
• Row counts per record are small (single or low double digits) and editing is infrequent.
• Your team is comfortable owning a small, low-traffic dependency — including the possibility of forking it. The MIT license makes vendoring or an internal fork a legitimate mitigation.
• You want the cheapest possible path to shipping editor-managed repeating content this quarter.

Look elsewhere when:

• You are not on PyroCMS. There is essentially no portability here; this is not a standalone Laravel repeater.
• You need to query, sort, filter, aggregate, or validate individual rows at the database level — denormalized storage will fight you, and a related model/child stream is the correct answer.
• The data is business-critical or has a long life. One star and zero dependents means no community, no security review, and no guarantee of maintenance; treat it as unmaintained code you are adopting.
• Deep nesting (repeaters inside repeaters) or large row counts are requirements — validate against your actual editorial use cases before committing.
• You are on Filament, Nova, or another admin framework with a first-party Repeater; use the native one and avoid a second content paradigm.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed add-on that lets content editors build repeating page sections themselves instead of filing engineering requests. The upside is speed and reduced engineering overhead on content changes; the cost is near zero in license terms. The real risk is maturity — the project has negligible community adoption — so we should adopt it deliberately: pin the version, plan to own a fork if needed, and avoid using it for data we'd ever need to report on or migrate. Recommend approving for presentation-layer content only.

To engineering: It's a Streams field type, not a general Laravel package — value is entirely contingent on staying on PyroCMS. It gives us a validated, admin-UI-ready repeater with no schema migration when content shape changes. Be explicit about the trade-off: repeated rows are stored on the parent record rather than as queryable entities, so anything that needs filtering, sorting, or joins should be modeled as a child stream instead. The codebase is small enough to audit in an afternoon and fork if upstream goes quiet, which is the main reason the low star count isn't disqualifying. Recommend a time-boxed spike against two real content templates before we standardize on it.