- Can I use rezozero/liform-bundle in a Laravel application?
- No, as packaged it is a Symfony bundle, not a Laravel package. It requires Symfony bundle registration, dependency injection service definitions, a configuration tree, and Twig form-theme support, none of which map to Laravel's provider and Blade lifecycle. The underlying liform library also carries symfony/form as a hard runtime dependency, so using it in Laravel means standing up Symfony's Form component as a second form and validation stack.
- What does LiFormBundle actually do?
- It integrates the liform library into Symfony to serialize Symfony Form types, fields, and options into JSON Schema metadata. That metadata can be exposed as JSON for JavaScript or React form renderers while submitted data is still processed and validated through Symfony's Form component. It is an adapter around Symfony Form, not a standalone JSON Schema form engine.
- How do I install and configure rezozero/liform-bundle?
- Install it with Composer as rezozero/liform-bundle, then register the bundle in your Symfony kernel, such as bundles.php, and configure its services following standard Symfony bundle conventions. Configuration uses Symfony's dependency injection, configuration tree, and Twig form themes. There is no Laravel service provider, config publishing, or Blade equivalent to follow.
- Does it support Laravel 10, Laravel 11, PHP 8.3, or Symfony 7?
- Laravel support is not applicable because this is a Symfony bundle. PHP and Symfony version support depends entirely on the package's composer.json constraints and its last commit date, so verify those before assuming PHP 8.3 or Symfony 7 compatibility. With zero stars, zero dependents, and single-maintainer provenance, there is no guarantee of a timely framework-version release.
- Is the generated JSON Schema a faithful representation of server-side validation?
- No, and it is permissive relative to actual server validation. Symfony validation constraints live in the Validator component, so only constraints that liform explicitly maps appear as JSON Schema keywords. Data transformers also mean the schema describes the transformed shape rather than the exact payload the client posts, and EntityType, ChoiceType with query builders, form event listeners, and collection prototypes do not map faithfully. Clients may therefore accept input that the server later rejects.
- Which JSON Schema draft does liform support, and will it work with react-jsonschema-form or JSON Forms?
- liform historically tracks draft-04 semantics with partial coverage of later drafts. Modern renderers such as react-jsonschema-form, Formily, and JSON Forms often assume draft-07 or 2020-12 keywords like if/then, dependentRequired, and $defs. Verify the emitted schema against your chosen renderer before committing engineering time.
- When does a JSON Schema form bundle like this make sense?
- The strongest case is when one team owns form definitions server-side, a second team renders them client-side with a schema-driven renderer, and you want to collapse a hand-maintained contract into one artifact. It can also help with API contract or documentation generation. If the need is narrower, such as one admin surface, hand-written schemas or an OpenAPI-first approach are cheaper and lower risk.
- What are Laravel-friendly alternatives to rezozero/liform-bundle?
- In Laravel, keep form and request validation native using FormRequest, validation rules, and Blade or Inertia components, then generate or hand-write JSON Schema for any frontend renderer. An OpenAPI-first contract can serve the same single-source-of-truth goal without introducing Symfony Form. Replicating the thin liform adapter concept in-house is typically days to a couple of weeks depending on form-type complexity.
- What production and maintenance risks should I check before adopting it?
- The package has zero stars, zero dependents, and single-maintainer provenance as an agency wrapper around Limenius' liform. That means no community CVE triage, no Stack Overflow corpus, and no external users to absorb the cost of discovering sharp edges. A composer audit against a stale transitive dependency tree is a live concern for anything internet-facing. Treat it as an internal-tool option only after explicit risk acceptance.
- How should I test a LiFormBundle integration before adopting it?
- In a Symfony sandbox, install it, define representative form types including EntityType, ChoiceType, collections, and data transformers, then compare the emitted JSON Schema with the actual posted payload and server validation results. Test the schema against your chosen frontend renderer and run a composer audit to inspect transitive dependencies. For a Laravel codebase, test the Laravel-native alternative instead of introducing Symfony Form as a subsystem.