- Does rogerdsh/liform-bundle work in a Laravel application?
- No. This is a Symfony bundle built around symfony/form and the Symfony Bundle/DI extension system, and Laravel ships neither by default. Using it in Laravel would mean importing a parallel framework's form subsystem to solve a problem Laravel already handles with FormRequest rules, laravel-data, or OpenAPI annotations. The integration cost exceeds writing a small schema generator against your own validation metadata.
- How do I install and configure rogerdsh/liform-bundle in Symfony?
- Install it with Composer and register the bundle in your kernel bundles list (or bundles.php for Symfony Flex), then enable the DI extension configuration. The bundle introspects existing FormType classes and exposes JSON Schema output, so most of the work is defining your form types rather than writing bundle-specific config. Because the package has zero dependents and a personal namespace, pin an exact commit hash via a VCS or path repository instead of relying on Packagist availability.
- Which Symfony and PHP versions does rogerdsh/liform-bundle support?
- This is the first thing to verify, because the package shows no adoption signal and likely predates current Symfony majors. Read composer.json for the symfony/form constraint and run composer why-not symfony/form:^7 to see whether it resolves cleanly. A stale pin on symfony/form is an application-wide blocker, not a local inconvenience, since that library is a shared transitive dependency.
- How is this different from the Limenius Liform bundle?
- rogerdsh/liform-bundle appears to be a personal fork or rename of the established Limenius Liform bundle, and its functionality is inherited entirely from the upstream Liform code. The naming difference means divergence from upstream is unverified, so patch adoption and vulnerability triage become manual work. Diff the source against upstream before trusting it.
- Which JSON Schema draft does the generated output target?
- Liform-era generators typically emit draft-04 or draft-06 style schemas, and draft 2020-12 support is unlikely given the package's vintage. Confirm this before wiring it into a frontend validator or API contract, because draft mismatches cause silent validation failures. If your consumers expect a modern draft, plan for a transformation layer or a different generator.
- Does it handle nested CollectionType, EntityType, form type extensions, and custom constraints?
- These are exactly the areas where schema generators fail silently, and there is no test evidence in the package to suggest they are covered. EntityType in particular can leak Doctrine metadata such as entity class names and choice identifiers into publicly exposed schemas. Build a proof of concept with your real form types, including FormTypeExtensions and dynamic choices, before committing.
- Is rogerdsh/liform-bundle safe to use in production?
- It has zero stars, zero dependents, and no advisories, which reflects a lack of scrutiny rather than proven safety. No production system is known to run it, so compatibility with PHP 8.x and current Symfony releases is untested. If you adopt it, vendor the fork internally, pin a commit, and review schema output for leaked constraint messages or entity metadata before exposing it publicly.
- Can I use it to drive client-side form rendering and validation in React or Vue?
- That is the intended use case: emit JSON Schema from Symfony form structure so a JavaScript form builder or validator can render and validate without duplicating rules. The bundle itself only produces the schema; the client-side renderer is your choice. Validate that the emitted draft and constraint keywords match what your chosen JS library actually supports.
- What are the alternatives to this bundle for generating JSON Schema in PHP?
- On Symfony, the upstream Limenius Liform bundle or a custom generator over FormType metadata are the natural options, alongside NelmioApiDocBundle if you are documenting an API. On Laravel, laravel-data, FormRequest rule introspection, or an OpenAPI-first workflow avoid the Symfony dependency entirely. The key decision is defining an internal SchemaGenerator contract so any of these can be swapped without a refactor.
- How should I mitigate the maintenance risk if I adopt it?
- Treat it as a replaceable implementation detail rather than a dependency: define an internal contract that takes a form descriptor and returns a schema array, and bind this bundle behind it. Pin an exact commit via a VCS or path Composer repository and vendor the fork internally so Packagist availability is never a concern. Identify an owner willing to fork and maintain it, otherwise it dies on the first Symfony major bump.