Orchid Repeater Field Laravel Package

Product Decisions This Supports

• Feature scoping for internal admin tooling. The core capability here is the "repeater" — a form control that lets an editor add/remove/reorder an arbitrary number of sub-form rows (line items, FAQ blocks, pricing tiers, multi-address records, contact lists). If your roadmap includes any "flexible content" or "list-of-things" authoring surface, this is the enabling primitive you are deciding whether to have.
• Build vs. buy vs. borrow for the admin layer. Orchid is a Laravel RAD/admin panel that historically lacked a first-party repeater. This package is the community patch for that gap. The real decision isn't "adopt this package" — it's "do we (a) fork and own this, (b) switch admin frameworks to one with native repeaters, or (c) hand-roll a Blade + Alpine/Livewire component ourselves."
• Content model / schema decisions. A repeater is frequently the front door to a badly-normalized JSON blob column. Adopting a repeater implies deciding whether repeated data lives in JSON columns (fast to ship, painful to query/report on) or in child tables (more migrations, better analytics). This package makes the JSON route cheap, which shapes downstream reporting and migration cost.
• Roadmap risk calibration for the Orchid bet. Zero dependents and an archived repo are signals about the health of the broader Orchid add-on ecosystem. If your admin layer is a multi-year commitment, that's an input to whether Orchid stays in the stack.

When to Consider This Package

• Only if you are already on Orchid and pinned to a version this was built against. Verify Laravel, PHP, and Orchid major-version compatibility before anything else — an archived package has no compatibility drift protection.
• As a reference implementation, not a dependency. Given archived status, MIT license, and 59 stars with 0 dependents, the realistic path is: vendor it into your codebase, review the code (small surface area), and own it. Treat it as a well-scoped starting point, not a maintained library.
• When the alternative is rebuilding from scratch and your team has PHP/Laravel capacity. The internal cost of owning ~a few hundred lines of form-field code is low; the cost of an unmaintained dependency in a shipped product is not.
• Look elsewhere if: you have no Orchid commitment (Filament, Nova, and Backpack ship repeaters natively — don't adopt an admin framework because of this package); you need nested/multi-level repeaters, drag-and-drop, or file uploads inside rows at production quality; your org requires a maintained dependency with a CVE response path; or your security posture blocks unmaintained third-party code in admin surfaces.

How to Pitch It (Stakeholders)

To executives: We have a small, well-defined capability gap in our admin tooling — the ability for content and ops staff to manage variable-length lists (pricing tiers, FAQ entries, line items) without engineering involvement. A community package closes that gap cheaply and is permissively licensed, but it has been archived by its author and has essentially no adoption, meaning no ongoing maintenance or security patching. Recommendation: use it as a reference to fork and own — a modest one-time engineering cost, versus either (a) building the control from zero, or (b) migrating admin frameworks. Do not add it as a live dependency.

To engineering: MIT-licensed Orchid form field adding repeater support; small surface area, worth reading end-to-end. It is archived with no dependents, so plan to vendor it, pin and document the Orchid/Laravel/PHP versions it works against, and add it to your internal maintenance list. Flag it if we're standardizing on maintained dependencies only — that constraint alone would push us to reimplement rather than fork.