Repeater Field Type Laravel Package

Technical Evaluation

Architecture fit. anomaly/repeater-field_type is not a general-purpose Laravel package — it is a satellite addon for the AnomalyLabs Streams Platform (the framework underneath PyroCMS 3). It plugs into the platform's field-type contract (FieldType base class + service provider + Twig-rendered control-panel input). Fit is therefore binary: strong if the target application is already a Streams/PyroCMS build, effectively zero otherwise. Do not evaluate it as a standalone Composer dependency.

Integration feasibility. Mechanically simple — composer require, provider auto-discovery, then attach the field type to a stream via the control panel. Real feasibility depends on the surrounding platform, not this repo: with 1 star, 0 dependents, and a single-maintainer org, this is a low-signal artifact with no production evidence to point at. Assume you are the first meaningful adopter.

Technical risk.

• Ecosystem staleness (high). Streams Platform and its addon family are largely dormant; Laravel/PHP version constraints in composer.json will likely cap you at Laravel 5.x/6.x and PHP 7.x. PHP 8.1+ compatibility is unlikely without a fork.
• Data model opacity (high). Repeater values almost certainly persist as a JSON/serialized blob in a single column, meaning repeated fields are not queryable, indexable, or joinable. This is the single biggest architectural constraint and must be confirmed before commitment.
• Config surface unclear (medium). Whether the repeated field set is defined declaratively per-field, hardcoded, or configured through a nested stream determines how reusable this is across models.
• No visible test coverage (medium). Small codebase makes it auditable, but there is no safety net for upgrades.

Key questions to resolve before any commitment.

1. Is the Streams Platform itself receiving security/compat releases, or is the whole stack frozen?
2. What is the exact persistence format, and does the platform expose a clean migration path off it?
3. Are repeated sub-fields configurable, or is the field set fixed in code?
4. How does it interact with translations, revisions/drafts, and the CP form builder?
5. Does a first-party or better-maintained alternative (grid, multiple, related) already cover the same use case?
6. Who owns the fork when this breaks?

Integration Approach

Stack fit. Only viable inside a Laravel + Streams Platform application. Twig is the control-panel view layer; admin UI behavior is driven by platform JS conventions. Any project on a modern Laravel (9/10/11) or PHP 8.2+ should treat this as incompatible until proven otherwise by a spike.

Migration path.

• Adopting: composer require anomaly/repeater-field_type pinned to the exact platform version, verify provider registration, then add the field type to a stream assignment in the CP. Backfill any existing structured data into the expected JSON shape via a one-off artisan command rather than hand-editing rows.
• Exiting: because data lives in a single blob column, plan the extraction as an explicit ETL step (read JSON → normalize → write relational rows). Never let this field type back a system of record without an exit script written on day one.

Compatibility. Pin anomaly/streams-platform in composer.lock and treat any platform bump as a breaking change requiring regression on every repeater field. If the project must run PHP 8+, budget for a fork: bump the constraint, fix Twig/typed-property deprecations, and add a smoke test around input rendering and save/load round-trip.

Sequencing.

1. Sandbox spike — install against your exact platform version, prove render + save + retrieve.
2. Data-model review — confirm storage shape, row-size limits, and query requirements; reject now if any repeated field must be filtered or sorted on.
3. Single-stream pilot in a non-critical area.
4. Fork + pin + document if the pilot passes.
5. Broader rollout only after the exit/ETL script exists.

Operational Impact

Maintenance. Treat as vendored code, not a dependency. Low LOC makes it cheap to own (~1–2 days to audit fully), but you inherit all bug fixes. Fork to your org, tag it, and add it to your internal registry. Budget a recurring line item for platform-upgrade regressions.

Support. No vendor, no SLA, no meaningful community — GitHub issues only, and with 0 dependents there is no crowd to lean on. Named internal ownership is a hard prerequisite; without it, this becomes orphaned code inside your product.

Scaling. Fine for small repeaters on low-volume content (a handful of rows per record). Degrades on three axes: (a) no index on repeated values, so reporting and search require application-side parsing; (b) JSON column size growth on unbounded repeaters — enforce a row cap in the field config; (c) control-panel render cost for large repeat sets. If the field feeds analytics, search, or filtering, this is the wrong primitive regardless of code quality.

Failure modes to instrument.

• Silent data loss when the field's sub-field configuration changes but existing rows retain the old key shape — add a schema-version key inside the stored JSON.
• Platform upgrade breaks Twig partial or CP JS, blocking form saves (fails closed, but late — in the editor's session).
• Orphaned JSON after disabling/removing the field assignment; ensure the column is not dropped implicitly.
• Composer resolution failure against newer Laravel, surfacing as a hard install break during unrelated upgrade work.

Ramp-up. Low for a developer already fluent in Streams/PyroCMS field types (half a day). Medium-to-high for a general Laravel team — the platform's stream/assignment/field-type abstractions and Twig admin layer are non-obvious. Plan ~1 week end-to-end to fork, harden, pilot, and document; do not staff this as a drop-in library install.

Verdict. Viable only as an internal fork inside an existing Streams Platform application with a small, well-bounded repeat requirement and a designated owner. The 0.525 score and 1-star/0-dependent profile accurately reflect adoption risk; the MIT license and small surface area are the only mitigating factors.