Weave Code
Forms Laravel Package
laravilt/forms
Laravilt Forms is a Laravel package for building and managing forms in code. It provides reusable form components and a structured way to define form schemas, helping developers create consistent, maintainable forms with a clean API and flexible configuration for modern Laravel applications.
Complete form builder system with 30+ field types, validation, and Blade/Inertia.js integration for Laravilt. Build complex forms with text inputs, selects, date pickers, file uploads, rich editors, repeaters, and more.
Frequently asked questions about Forms
- How do I install and configure laravilt/forms in a Laravel application?
- Install it with composer require laravilt/forms, then install the matching JavaScript bindings from npm and publish the package assets and config. Because forms are defined in PHP and rendered by the frontend, the PHP package and its Vue or React package must stay on the same version. laravilt/forms is part of the Laravilt ecosystem, so it also expects laravilt/support and the usual Laravilt conventions to be in place before forms render correctly. Pin exact versions rather than floating ranges while the ecosystem stabilizes.
- Which Laravel and PHP versions does laravilt/forms support?
- The package targets modern Laravel releases and builds on the Laravilt support package, so check the compatibility matrix for the exact PHP, Laravel, Node, and Vite versions you run. Release notes for v1.1.0 reference Laravel 13 compatibility, but Laravel 13 is not GA, so treat that as forward-compatibility testing rather than verified production support. You also need every laravilt package and its npm sibling resolved to a mutually tested combination, since localization now imports from laravilt/support.
- How do I define a form with laravilt/forms?
- Forms are defined PHP-side as a structured schema of fields, each with a type, name, label, and validation rules, and the package renders that schema through Blade or Inertia. You compose fields like text inputs, selects, and repeaters into a form definition, then return it to your view or Inertia page. Keeping the schema in PHP gives you a single source of truth for validation and rendering across the application. That is what makes forms reusable and consistent compared with hand-writing markup per page.
- What field types does laravilt/forms include?
- laravilt/forms ships 30+ field types, including text inputs, selects, date pickers, file uploads, rich text editors, and repeaters for nested or dynamic data. Version 1.1.0 adds TranslatableInput for multi-language values. Each field type has its own serialization and rendering behavior, so check the docs for a specific type before assuming how its state is stored. Most standard form needs are covered without writing custom components.
- How does validation work in laravilt/forms?
- Validation is declared alongside the field in the PHP schema, so rules travel with the form definition instead of being duplicated in controllers and views. Because the schema drives both the backend rules and the frontend rendering, you get consistent error display in Blade and Inertia. Review behavior between 1.0.8 and 1.1.0 if you rely on custom form lifecycle hooks, since rendering paths were rewritten in both stacks. Cover validation failures as well as successful submissions in your tests.
- Should I use the Vue or React renderer with laravilt/forms?
- Version 1.1.0 promotes React to a supported rendering stack alongside Vue, meaning the package now ships two parallel client implementations of the same contract. If your application is already on Vue, stay on Vue; the React addition is not a reason to migrate and it doubles the surface area your team must reason about. React is the sensible entry point for greenfield React applications, but treat it as early-adopter until docs, tests, and deprecation policy show parity with Vue. Long-term ownership of the React implementation is worth confirming with the maintainers.
- Is laravilt/forms v1.1.0 safe for production and should I upgrade from 1.0.x?
- If you have no prior assessment, treat v1.1.0 as your baseline rather than an upgrade target, and if you are on 1.0.x the two-factor page crash fix alone justifies moving up. That defect could break an authentication-adjacent flow, which is a reliability issue rather than cosmetic. It is a minor version with a major-version blast radius, so upgrade in a sandbox, exercise auth and two-factor pages explicitly, run existing form regression tests against the Vue path, then roll out behind the auth surface first. Do not adopt TranslatableInput in the same change window as the version bump.
- What is TranslatableInput in laravilt/forms and does it require migrations?
- TranslatableInput is a new field type added in v1.1.0 for editing values across multiple locales. It carries serialization and schema implications, so confirm in the documentation whether it changes persistence contracts or requires migrations before using it on existing data. Because it is new and shipped in a minor release, separate the version upgrade from adopting the feature. Test it against your storage layer in a sandbox first.
- How do I test forms built with laravilt/forms?
- Test the PHP side like any Laravel form: assert the schema, field definitions, and validation rules with PHPUnit or Pest, and cover validation failures as well as successful submissions. For the frontend, assert Inertia props or rendered Blade output rather than the full component tree, since rendering paths differ between Vue and React. Add an explicit regression test for any authentication or two-factor pages that use forms, given the crash fixed in 1.1.0. This keeps the upgrade verifiable rather than assumed.
- What are alternatives to laravilt/forms, such as Filament or Livewire form builders?
- Alternatives include Filament and Livewire-based form builders, which keep everything in PHP with a server-driven frontend, and plain Blade or Inertia form handling if your forms are few and simple. Choose laravilt/forms when you are already standardized on Laravilt and want a PHP-defined schema rendered by Vue or React without bespoke form code. Adoption is an ecosystem-level commitment involving Laravilt conventions, the support package, and frontend build changes, not a single Composer dependency. If you are evaluating it standalone, weigh those costs before committing.
Weaver
How can I help you explore Laravel packages today?