Laravel Form Builder Laravel Package

Getting Started

Install and publish

composer require anthonyedmonds/laravel-form-builder
php artisan vendor:publish --provider="AnthonyEdmonds\LaravelFormBuilder\FormBuilderServiceProvider"

The package follows the standard Laravel package conventions, so the publish step is the important one — check what tags it exposes (--tag=config, --tag=views) and only publish the views if you intend to override them. Current line is 2.6.x; 2.6.2 is a patch on top of 2.6.1, so anything you read for 2.6.x applies.

Where to look first

1. config/form-builder.php (or similarly named) after publishing — this is where the framework-level defaults live (view namespace, CSS framework / styling assumptions, wrapper markup).
2. The package's src/ root — identify the base form class and the base field/control class. Almost every customisation you'll do in a real project is a subclass of one of those two.
3. The published or package-provided Blade views under resources/views/vendor/... — this is the ground truth for what markup you actually get, and it answers most "why is this rendered like that" questions faster than the docs.

First use case

The canonical first use is: define one form class for a real form in your app (e.g. a contact or profile form), declare its fields and validation rules in that class, then render it from a controller-provided instance in a Blade view. Resist building a generic form abstraction on day one — create a single concrete form, render it, submit it, and confirm the old-input/error repopulation behaviour works. That end-to-end loop exercises the parts of the package most likely to surprise you.

Implementation Patterns

Form-as-a-class

The core pattern is a PHP class per form, holding field definitions and validation rules together. This is the main value over hand-written Blade: rules, labels, and input types live in one place, so a field rename is a single edit rather than a grep across views and request classes. Keep these classes thin — field definitions and rules only. Business logic belongs in an action or service, not in the form class.

Validation

Prefer letting the form class own its rules and wiring that into a FormRequest or a controller validate() call, rather than duplicating rules in two places. Where the package derives rules from field definitions, use that direction (fields → rules) instead of the reverse, so adding a field cannot silently skip validation.

Rendering and overrides

Render via the package's Blade components/directives in your views rather than reaching into field objects manually. When the default markup doesn't match your design system, override the individual view rather than editing vendor files, and keep those overrides in version control with a comment naming the package version they were copied from. Overrides are the most common source of breakage on minor upgrades (see below).

Composition

For larger forms, group fields into sections/fieldsets and build the form from those groups. This keeps individual classes readable and lets you reuse a field group (address block, contact details) across multiple forms. If the package supports partials or sub-forms, prefer those over copy-pasting field definitions.

Integration tips

• Pair with your existing layout: render the form inside a normal Blade view and let the package handle fields only, rather than letting it own the whole page.
• Test the submit path, not just the render path — feature tests that POST the form and assert both validation errors and the success redirect catch most integration mistakes.
• If you use Livewire or Inertia anywhere in the app, keep this package confined to the classic server-rendered forms; mixing paradigms in one form is where the seams show.

Gotchas and Tips

2.6.2 specifically

• The 2.6.2 fix addresses an "empty button" rendering issue. If you have a locally overridden button view, that override will not receive the fix — compare your published view against the upstream one after upgrading. This is the standard risk with any patch release touching views.
• No breaking changes, no deprecations, no config changes in 2.6.2. It is a safe patch upgrade from 2.6.1; pin with ^2.6 and let it in.

Debugging

• Wrong markup almost always means either a stale published view or a config default you didn't know about. Delete/republish the views to a scratch directory and diff before assuming a bug.
• If a field renders but its value doesn't repopulate after a failed validation, check the field's name matches the request key exactly — this is the single most common cause.
• Old-input behaviour depends on the session middleware; forms tested in isolation outside the web group will appear broken.

Config quirks

• Published config is a snapshot, not a live reference. New config keys added in a minor release will be silently missing from your published file and fall back to package defaults. After any minor bump, diff your config against the package's current version.
• Similarly, published views shadow package views. Keep a short list of what you've published so upgrades are a checklist, not archaeology.

Extension points

• Subclass the base form and field classes rather than monkey-patching; project-wide tweaks (a default CSS class, a standard hint format) belong in one base subclass that all your forms extend.
• Keep custom field types narrow and single-purpose. A field class that takes six constructor flags is a sign it should have been two fields.

Upgrade discipline

• Treat minor versions as reviewable: read the changelog, diff published config and views, run the form feature tests. Patch versions like 2.6.2 can be taken on trust.
• Because the package is view-heavy, visual regression is the realistic failure mode — a smoke test that asserts key markup or form field names present in the rendered response is cheap insurance.