Nova Repeatable Fields Laravel Package

Technical Evaluation

Architecture fit. This is not a general Laravel package — it is a Laravel Nova field class plus a Vue component. Its entire architectural surface is one layer of the stack: the admin resource definition. It owns no table, no service provider logic of consequence, and no runtime behaviour outside Nova forms. Data lands as a JSON blob on the parent model with an array cast. That makes the fit narrow but clean if and only if three conditions hold: we run Nova, the content is admin-facing and low-stakes, and the data is form-shaped rather than report-shaped. It fails the fit test as soon as anyone asks "how many records have a Monday opening row?" — that becomes a JSON path query, tolerable only on MySQL 8.0+ with generated columns.

Integration feasibility. High on the happy path, and that is the trap. Install is a pinned composer require, one nullable json column, one cast, one resource edit. Hours, not weeks. The actual engineering effort is entirely in the things the package does not do: wildcard validation rules on the parent model, a saving normalizer to array_values() the payload, a row cap, readable attribute names, and a Dusk test for add/remove/reorder because those interactions are Vue-side and invisible to HTTP tests. Budget for that work, not for the install.

Technical risk. Archival status is the headline risk, not a footnote. Last release 2019-06-10, zero dependents, 132 stars. Every Nova major is an unbounded break with no upstream remedy — the Vue 2 → 3 transition is the concrete example. Zero dependents means there is no crowd-sourced patch path and no de facto maintenance. Secondary risks: field-type coverage is a fixed set inside the Vue component (BelongsTo, File, async/modal fields typically fail), no reactive dependencies between subfields (dependsOn, hideWhen unsupported), null-hole serialization producing JSON objects instead of arrays, and DOM/payload degradation past roughly 30–50 rows.

Key questions to resolve before any code is written.

• Which Nova major are we on, and does it ship a native repeater or a maintained community alternative? If yes, this package has no justification.
• Is this a dependency decision or a fork decision? Given the archive, it should be treated as a fork: MIT lets us copy src/ and resources/js/ into our namespace, tag it, and name an owner.
• Will this data ever need cross-record search, aggregation, export, or reporting? If yes, stop — use a child table.
• Are accessibility and localization hard requirements? The auto-incrementing heading is client-side only, renumbers after add/remove/reorder, and is unverified for semantic markup and translatability.
• What is the orphan-column disposition if the field is later removed?
• The roadmap signal worth carrying forward regardless of the decision: the wide gap between the opportunity score (15.25) and the composite score (1.38) says "repeater fields are worth having," not "this is the repeater to have." That is a standing build-vs-buy prompt for our admin tooling, and it survives rejecting this specific implementation.

Integration Approach

Stack fit. Nova + Laravel only. Without a Nova licence this package scores zero and the capability question moves to whichever admin layer we actually run. Confirm the Laravel/Nova version pairing against a 2019-era field class before committing; the package has not tracked framework changes since.

Migration path and sequencing.

1. Gate: version and alternative check. Verify Nova major, confirm no native repeater, confirm no maintained alternative. This is a go/no-go, not a research task.
2. Pin exactly. composer require fourstacks/nova-repeatable-fields:1.3.0. Do not float the constraint. Record the rationale in the commit message — future engineers will otherwise "helpfully" un-pin it.
3. Choose the pilot deliberately. Low-traffic resource, four or more subfields so layout is exercised. Opening hours or an FAQ list. Explicitly not line items or addresses — those carry reporting implications and will fail under scrutiny, poisoning the pilot.
4. Data layer. Nullable json column, array cast, saving normalizer with ->values(), wildcard validation rules, attributeNames() for readable errors, max: on the array for the row cap.
5. Rehydration. If transforming in prepareForValidation, filter only entirely empty rows and transform idempotently — an aggressive filter drops a row the user was mid-way through filling on validation failure.
6. Derived values stay accessors. Never persist a total or computed duration alongside the blob; it goes stale the moment a row is reordered without saving.
7. Test. Feature tests on the resource endpoints plus one Dusk test: post three rows, delete the middle, reorder, save, reload, assert the stored array is sequential with expected values.
8. Fork and own it. Copy into vendor namespace before the second consumer adopts it, not after.
9. Write the one-page internal field guide, then expand beyond the pilot or drop the column.

Compatibility and migration from a child table. If displacing an existing child table, treat it as a one-way content migration: write the reverse migration first, map rows in a console command against a scratch column, compare counts, then swap the column name in a second deploy. Not one deploy. Also note the operational trap — Nova assets are compiled, so a stale build is the usual cause of "the field doesn't appear at all"; npm run dev/prod in the Nova directory is the fix.

Operational Impact

Maintenance. There is no upstream. The maintenance plan is the fork decision, and it must be made at adoption rather than at the first Nova upgrade. Cost is low — one PHP class, one Vue component — but it needs a named owner and an internal tag. Leaving it as an unowned third-party entry in composer.json is the failure mode that turns a 2019 archive into a 2024 incident.

Support. No support policy, no patch cadence, no expected response. The community contribution behind v1.3.0 is a historical data point, not evidence of ongoing health. The internal field guide becomes the support artifact: column type and cast, wildcard rules, normalizer, row cap, fork owner. Without it, the next developer hits vanished rows within a week and files a bug against a dead repository.

Scaling. Two independent ceilings. First, the form: no pagination, no lazy loading — beyond roughly 30–50 rows the UI gets sluggish and the save payload gets fat, so cap it in validation with max: and surface a clear message. Second, the data: blob queries degrade fast. "Every opening-hours row where day = mon" is awkward on MySQL 5.7 and only tolerable on 8.0+ with generated columns and indexes. No row-count limitation should be allowed to become a reason someone builds an unindexed JSON query in production.

Failure modes and their signatures.

• "All rows vanished." Null holes from deleted rows serialize as a JSON object rather than an array. Fix is ->values() in the normalizer; check getRawOriginal() before escalating.
• Stale derived totals. Persisted instead of computed. Fix is an accessor, applied at design time.
• Missing validation. The package stores a blob and enforces nothing. Every shape constraint is ours to write.
• Field type silently fails. Each type used must be tested, one resource at a time.
• Stale Nova asset build. Field absent entirely; no server-side error.
• Orphan column. Left behind after removal; decide drop-or-retain up front.
• Misread heading numbers. The counter is client-side and renumbers on reorder — nothing may be built on those values.

Ramp-up. Low for competent Nova developers — the README and src/Repeatable.php are sufficient to ship a first field in a day. The risk is not learning the package; it is that the package is trivial to use and easy to misuse, and all the failure modes above are discovered by the second developer, not the first. Mitigate with the field guide and the Dusk test at adoption time, and treat the pilot as an evaluation of our data-model judgement as much as of the package.