Nova Collection Field Laravel Package

Product Decisions This Supports

• Build vs. buy on form plumbing: Nested/array-shaped form payloads (repeaters, multi-step wizards, settings screens, dynamic field groups) are undifferentiated glue code that every team rewrites. This package is a candidate to remove that work from the roadmap rather than staff it.
• Feature scoping — validation was the gating gap. Adding validation support in 0.3.0 changes the calculus: previously you'd decorate nested data and then hand-roll a parallel validation path outside the package, which is exactly where bugs and drift live. Server-side rule enforcement on decorated data makes the package viable for real form surfaces, not just serialization.
• Roadmap signal: The nested form data decorator refactor indicates the maintainer is investing in the core nested-data abstraction — the actual differentiator versus flat form builders. Treat it as evidence of direction, not of stability (see risk below).
• Concrete use cases to evaluate against: admin/back-office panels with repeating field groups, multi-step onboarding, tenant-configuration screens, and any endpoint where the request payload is a nested structure that must be validated and normalized before persistence.
• Sequencing decision: this is a pilot candidate, not a platform commitment. Scope it to one low-blast-radius surface to buy information on API churn and maintenance responsiveness.

When to Consider This Package

Consider it when:

• Your forms genuinely carry nested/array payloads and you are currently writing custom casting, hydration, or recursive validation by hand.
• You want Laravel-native validation rules applied to the decorated structure rather than maintained in a second, parallel code path.
• You have a small team with limited appetite for owning a bespoke form layer, and can absorb pre-1.0 API movement.
• The form surface is internal-facing or otherwise tolerant of iteration during the 0.x window.

Look elsewhere when:

• Stability is a hard requirement. This is a 0.x package, and 0.3.0 lists a refactor of the nested form data decorator — the core abstraction — under "Changed." That is a likely breaking change with no major-version signal. Verify against the upgrade notes before committing; do not assume "Changed" here is non-breaking.
• You need rendered UI components, client-side state, or a full form-builder experience — this is a data/decorator concern, not a front-end one.
• You need commercial support, SLAs, security review artifacts, or an audited dependency for a regulated surface.
• Your team already standardizes on a mature form-object pattern (e.g. Livewire form objects, a first-party DTO/hydration layer) — the marginal value drops sharply and you'd be adding a second idiom.
• Your engineers are unfamiliar with the decorator pattern; the abstraction cost will show up in onboarding and code review.

How to Pitch It (Stakeholders)

To executives: A small open-source Laravel package that removes hand-written code for nested form data, now with built-in validation — the piece that previously made it impractical. Cost of adoption is roughly a day of engineering on a single surface. The trade-off is maturity: it's pre-1.0, so recommend a scoped pilot with a documented exit path rather than a platform-wide standard. Success looks like one form surface shipped with less custom code and no validation drift.

To engineering: 0.3.0 adds validation support, closing the main functional gap, and refactors the nested form data decorator. The refactor is the item to diligence: confirm whether it's breaking and what the migration path is before we build on the nested API. Proposed next step is a one-surface spike — wire up a representative nested payload, apply existing validation rules, and report back on API ergonomics plus upgrade risk. If the spike is clean, we expand; if the decorator API is still moving, we wait for 1.0.