Form Laravel Package

Product Decisions This Supports

• Form-heavy delivery work (admin panels, internal tools, settings/onboarding flows). Where forms dominate the backlog, a fluent builder that turns repetitive Blade markup plus validation wiring into declarative field definitions is a real velocity lever. That is the problem this package advertises; it is not yet a solution we can schedule against.
• Build vs. buy for the form layer. This package currently informs the "build" side only — as an API-ergonomics reference (chainable field builders, macros, publishable views), not an adoptable dependency. The decision it actually supports is whether to invest in an internal form abstraction at all.
• Roadmap and resourcing. Nothing should be committed to this dependency. The defensible roadmap item is a 1–2 day discovery spike if form work is already funded, with a go/no-go gate at the end.
• Design-system consistency. Publishable view templates and custom macros are the right primitives for enforcing org-wide field styling and validation behavior — worth citing as requirements when we evaluate or build an alternative, even if this package isn't the vehicle.
• Positioning risk as an input. The repo describes "form input components for Laravel Livewire"; the package doc describes a general Laravel form builder. That divergence suggests unresolved scope, which is itself a reason not to bet a roadmap on it.

When to Consider This Package

Adopt-worthy criteria (none are currently met):

• A tagged release beyond v0.0.1 with a documented public API and changelog.
• A published PHP/Laravel compatibility matrix with CI evidence.
• Confirmed service provider registration/package discovery and a documented config publish contract.
• Visible maintainer responsiveness and a release cadence signal.
• A named internal owner willing to fork and support it if upstream goes quiet.
• Evidence the alternative is measurably worse for our use case.

Look elsewhere when:

• There is any production timeline at all. Zero stars, a single "Init commit," and no release since October 2022 reads as abandoned, not early-stage — those look identical from the outside, and we can't afford to find out which.
• The need is Livewire-specific: Livewire's own form objects and wire:model cover most of this natively with no vendor risk.
• The need is server-rendered HTML forms: Laravel Blade components plus spatie/laravel-html or a maintained Collective-HTML fork are boring and battle-tested.
• A security or compliance review applies — there is no disclosure process and no visibility into the dependency tree.

How to Pitch It (Stakeholders)

Executives: This is not yet a build-vs-buy decision we can make. The package is a pre-alpha scaffold — one commit, no release in over two years, no users, no documentation of supported versions. We recommend against adoption. The underlying problem is real: form boilerplate consumes engineering time across our CRUD and settings screens. So we're proposing a one-week, time-boxed evaluation comparing Laravel/Livewire native form primitives against one mature alternative, decided on evidence. The cost of guessing wrong here is an orphaned dependency we own and maintain forever.

Engineering: Use this as an API reference, not a dependency. Do not add it to composer.json. If anyone wants to explore it, time-box it in a throwaway Laravel app and answer five questions: supported PHP/Laravel versions, service provider registration, public API surface, test coverage, and config contract. In parallel, standardize on Blade components + FormRequest, or Livewire form objects — same ergonomics, zero vendor risk. Any form-layer library entering the stack requires an ADR and a named internal owner first.