Weave Code
Liform Bundle Laravel Package
survos/liform-bundle
Survos Liform Bundle integrates Liform with Symfony to turn JSON Schema definitions into usable Symfony forms and Twig-rendered form UIs. It helps teams build schema-driven forms, keep validation and rendering aligned, and support dynamic data entry in admin tools and applications.
READONLY fork of https://github.com/answear/LiformBundle
Frequently asked questions about Liform Bundle
- Can I use survos/liform-bundle in a Laravel application?
- No, not as packaged. survos/liform-bundle is a Symfony bundle whose main artifact is dependency-injection wiring: a bundle class, a DI extension, and a config tree that registers Liform services into the Symfony container. Laravel has no bundle registration or AppKernel, so that wiring is inert inside a Laravel app. The actual JSON Schema transformation capability lives in the underlying Liform library and symfony/form, not in the bundle wrapper.
- What does survos/liform-bundle actually do compared to the Liform core library?
- The bundle integrates Liform with Symfony so JSON Schema definitions can be turned into Symfony forms and Twig-rendered form UIs. Most of its code is container wiring and configuration rather than transformation logic; the real work of converting form definitions to JSON Schema happens in the Liform transformer and the Symfony Form component. For a Laravel evaluation, that means the bundle itself is largely irrelevant and only the upstream library matters.
- Is survos/liform-bundle maintained and safe to use in production?
- Treat it as high risk. It is a READONLY fork of answear/LiformBundle with roughly one star, zero dependents, and a single-maintainer organization, which implies no external upgrade pressure, no security-response channel, and no bug reports being triaged. There is no observable downstream usage to signal stability. The MIT license is the one clearly favorable factor, since it lets you fork or vendor the logic instead of depending on the package.
- How do I install survos/liform-bundle and register it?
- Installation is a normal Composer require followed by registering the bundle in a Symfony kernel and enabling its extension in configuration. In Laravel there is no equivalent registration step, so a service provider would have to construct the form factory and the schema transformer directly. At that point you are bypassing the package rather than installing it.
- Which Laravel and PHP versions does this package support?
- The bundle does not declare Laravel support at all, because it targets Symfony. Any Laravel compatibility is indirect, coming from Symfony components Laravel already ships such as HttpFoundation, Finder, Console, and VarDumper, and version constraints on symfony/form are likely to conflict with those. Check the composer.json constraints on php, symfony/form, and the Liform core version against your current baseline before assuming it will resolve.
- What should I use instead of this bundle for JSON Schema generation in Laravel?
- Laravel has healthier native routes. dedoc/scramble generates OpenAPI 3.1, which is JSON-Schema-aligned, directly from FormRequests; spatie/laravel-data gives you typed DTOs with TypeScript and contract generation; and a thin in-house mapper can turn rules() arrays into JSON Schema property nodes. All three keep the dependency graph inside the Laravel ecosystem and avoid carrying a second form system alongside Laravel's validation stack.
- Can I pull in symfony/form and the Liform transformer standalone without the bundle?
- Yes, and that is the only realistic integration path. symfony/form needs OptionsResolver, EventDispatcher, PropertyAccess, Validator, and HttpFoundation, all of which are Composer-installable and usable in isolation, and a Laravel service provider could construct the form factory and schema transformer directly. The catch is architectural: you would run two sources of truth for field definitions next to Laravel's own request and validation layer. The practical move is to spike the transformer, capture its output for one real form, and compare it with what a Laravel-native mapper produces from the equivalent FormRequest.
- Which JSON Schema draft does the output target?
- This must be verified before any commitment, and the bundle itself does not settle the question. The relevant concern is whether the emitted schema targets draft-04 or a modern draft such as 2020-12, because that determines whether a front-end consumer like react-jsonschema-form or a current validator will accept it. Run the transformer against a representative form and diff the output against your consumer's expectations.
- Am I allowed to fork or vendor the Liform transformer into my own codebase?
- Yes. The MIT license explicitly permits forking, vendoring, and reusing the transformer logic, which is the single unambiguously favorable factor here. That reframes the decision from adopting a package to porting roughly a couple hundred lines of transformer code. It also removes the bundle entirely from your long-term dependency surface, along with its unmaintained upgrade burden.
- Is the upstream Liform library still maintained, or is this fork downstream of an abandoned project?
- That is a key question to close before committing. survos/liform-bundle is a READONLY fork of answear/LiformBundle, so maintenance health depends entirely on the upstream Liform library and the original bundle. With zero dependents and no triaged bug reports, expect no external upgrade pressure and budget for compatibility breaks yourself. Also confirm whether your need is runtime dynamic form rendering or API contract and documentation generation, since the latter has much stronger Laravel-native answers.
Weaver
How can I help you explore Laravel packages today?