Laravel Form Components Laravel Package

Product Decisions This Supports

• Build vs. buy for form rendering. Building an in-house Blade component library is a 2–4 week effort plus ongoing ownership. This package delivers the same surface — model-bound inputs, selects, textareas, checkbox/radio groups, toggle switches, file inputs, submit/link buttons, plus a form wrapper that handles CSRF, method spoofing, and :bind hydration — for the cost of a composer require. The buy case is clear if the stack criteria below hold.
• Roadmap sequencing around Livewire. The compatibility matrix pins Livewire ^2.0 across every release line, including 1.3.x. If our roadmap contains a Livewire 3 upgrade, this dependency creates a real ordering constraint: either those screens stay on Livewire 2, get routed through a different component strategy, or we absorb a fork. This is a planning input, not a detail to discover mid-sprint.
• Front-end framework standardization. The package supports Bootstrap 5 and Bootstrap 4 today; TailwindCSS 3 is documented as upcoming, not shipped. Adoption effectively ratifies Bootstrap as our form layer for the planning horizon. That is a legitimate decision to make deliberately — just don't make it by accident.
• Delivery velocity on form-heavy surfaces. Value scales with form count, not app count. A back-office CRUD panel with thirty-plus forms is the ideal target; a marketing site with two contact forms is not worth the dependency. Use this as the scoping heuristic when prioritizing which modules adopt it.
• Legacy migration de-risking. If we carry okipa/laravel-bootstrap-components, this is a documented, near-1:1 migration with an upgrade guide — a bounded refactor rather than an open-ended rewrite. That's a cheap technical-debt reduction to schedule.
• Not a design system, not a validation engine, not a form-state manager. Scope requirements accordingly. Any ticket that assumes otherwise is a misuse, and the mis-scoping will surface as "the package doesn't work" rather than "we asked it to do something it never claimed."

When to Consider This Package

Adopt when all of the following hold:

• Laravel 9–13 on PHP 8.1+ (1.3.x), or pinning to the appropriate older line.
• Bootstrap 4 or 5 is already our CSS framework. If this fails, the case collapses entirely — no amount of remaining merit recovers it.
• The target screens are Livewire 2, or are plain Blade forms that don't need reactivity.
• We have a meaningful volume of forms to build, and a named internal owner plus a fork plan if upstream goes quiet.
• We do not require a support contract, SLA, or named security counterparty. Procurement will ask; the answer is no.

Look elsewhere when:

• Tailwind is the house style. Wait for the TailwindCSS 3 release to actually ship, or evaluate alternatives. Do not plan against "upcoming."
• Livewire 3 is on the near roadmap and these screens must be reactive.
• The surface is small. Two or three forms do not justify a dependency with a bus factor of one.
• We need a maintained, contracted vendor relationship. 19 stars, 0 dependents, single donation-funded maintainer. We would be an early adopter, not a follower.

Risk profile to accept openly: bus factor of one; historically tight PHP version locking (1.2.0 "locked PHP versions to 8.1 and 8.2"), meaning minor runtime bumps can strand the package between maintainer releases; and 1.3's Laravel 12/13 support arriving 2026-05-11 as a catch-up release rather than continuous tracking. Mitigation is straightforward — pin the exact version in composer.json rather than using a caret range — but it must be an explicit decision, not a default.

How to Pitch It (Stakeholders)

To executives: This is a small, additive, MIT-licensed library that removes repetitive form markup work from our Laravel views. It's view-layer only — it doesn't touch routing, persistence, or auth, so it carries no architectural lock-in and is reversible at any time. Expected effort is 1–2 engineering days including a spike, against a 2–4 week build-it-ourselves alternative. The trade-off is dependency risk: it's maintained by a single developer with a small user base. We mitigate by pinning the version, naming an internal owner, and keeping a fork path. Recommend a one-sprint spike on a single module before any broader commitment.

To engineering: Integration is a composer require with no mandatory config, migrations, or queue footprint. Components are Livewire 2 compatible and support Bootstrap 4/5. Two hard constraints to plan around: Livewire 3 is not supported on any release line, and PHP/Laravel version ranges have historically been pinned tightly — so pin the exact package version. Start by writing new views with x:form::* (zero changes to existing code), prove the pattern on one real module, then expand. If we're coming off okipa/laravel-bootstrap-components, there's an upgrade guide and near-1:1 call mapping — treat that as a bounded migration, migrate one module, and stop if the pattern doesn't hold.