Forms Laravel Package

Product Decisions This Supports

• Build vs. buy for the admin form layer. This package is a candidate answer to "do we keep hand-writing Blade forms + FormRequests, or adopt an abstraction?" It is a tactical time-saver, not a platform bet — size the decision accordingly.
• Feature velocity on admin CRUD. Fluent field builders plus validation rules defined alongside fields means adding a field is one edit in one class, not a coordinated change across controller, request, and template. That directly compresses cycle time on back-office screens.
• Single source of truth for create vs. edit. Reusable form classes shared across both screens remove a well-known class of drift bugs (rule updated on create, forgotten on edit).
• Consistency of the admin surface. Publishable Blade views let you either align the admin UI to your design system or accept the package's defaults. That's a real product decision about brand consistency vs. setup cost, and it should be made once, explicitly.
• Filtering semantics — the decision hiding in v0.2.11. The package previously treated "all conditions filtered out" as valid and ran an unfiltered query; it now raises an error. Every PM owning a filtered list view or export has an equivalent unanswered question: does an empty filter mean show everything, show nothing, or reject the request? This release forces the third answer. Anything relying on the first (default "all records" dashboards, internal jobs, CSV exports) becomes a scoped migration item, not a bug.
• Roadmap input on admin tooling investment. The package's churn profile (pre-1.0, behavioural changes in patch numbers) argues for funding a thin internal abstraction rather than deepening a third-party dependency.

When to Consider This Package

Consider it when:

• You are on Laravel with an existing admin/back-office surface and repetitive form code is a measurable tax.
• Blast radius is low: internal tools, admin panels, screens where a 422 is an inconvenience rather than a customer-facing incident.
• You are willing to pin the version (^0.2.11), read the source, and own the upgrade diff yourself.
• Colocated validation and reusable form classes are worth more to you than ecosystem maturity.
• You can absorb the v0.2.11 semantics change: you have audited (or can grep) code paths that intentionally send no conditions.

Look elsewhere when:

• Adoption and maintenance signals are weak. Zero stars, a single-maintainer footprint, and no release since February 2023 mean no security-patch cadence and no community backstop. That is disqualifying for anything on a compliance or SLA path.
• You need semver you can trust. Pre-1.0 with behaviour changes shipped in patch versions is acceptable for a spike, not for a shared platform dependency.
• Your team can't read the changelog. Release notes are single-line and in Chinese. Every upgrade requires reading the diff. Budget for that or don't adopt.
• You need capability beyond the described scope — conditional field logic, complex file handling, Livewire/Inertia/Vue front-ends, i18n of the form layer. None of that is evidenced here.
• You'd have to fork it. Forking an unmaintained 0-star package is a permanent tax with no upside over writing the 200–400 lines you actually need.
• You want a mature admin framework. If the real requirement is a full admin panel (auth, tables, filters, actions), evaluate actively maintained frameworks in the Laravel ecosystem first; this package only covers the form layer.

Recommendation: conditional spike, not broad adoption. Run one team through it on a single admin module behind an internal interface, timebox two weeks, and decide on measured delta in form-code volume. If it wins, wrap it so replacing it later is a one-file change.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated a small open-source Laravel form builder that centralises admin form structure, validation, and rendering in one reusable class. It would modestly reduce the cost of building and maintaining back-office screens. It is not a strategic dependency: it has no meaningful community, has not shipped since early 2023, and changes behaviour in patch releases. Recommendation is a bounded two-week trial on one internal module, isolated behind our own interface, with no commitment to wider rollout. Downside risk is capped at the trial cost; upside is a measurable reduction in repetitive admin work.

For engineering: Fluent, declarative form classes with Laravel validation rules colocated; Blade rendering with publishable views; clean fit with FormRequests and Eloquent. Adopt at a pinned ^0.2.11, confirm service-provider discovery, publish and read the config before writing anything (validation strictness is config-driven). Put the assemble-filter-validate call in exactly one action class so the empty-condition semantics live in a single call site. Write a test per endpoint that filters to zero conditions and asserts the error. Watch falsy filters — 0, '0', false, and empty arrays are the usual casualties of truthiness checks.

For risk owners: Two things to log. First, the v0.2.11 change is a behaviour change, not a cosmetic fix — code that deliberately sends no conditions will start failing, and it was previously allowing unfiltered queries through. Audit before deploying, and if you must keep the permissive path temporarily via the config flag, file a ticket with an owner and a date to remove it, because that flag is the one that lets a full-table scan through. Second, treat the dependency as replaceable: no shared base classes, no subclassing of the initializer, no package types leaking into domain code. If it is abandoned, the exit should cost days, not a quarter.