Liform Bundle Laravel Package

Product Decisions This Supports

• Framework reality check first: despite being categorized as a "Laravel/PHP" package, limenius/liform-bundle is a Symfony Bundle wrapping the limenius/liform core library. It only supports decisions where the backend is Symfony (or where you are explicitly weighing a Symfony-based service against your Laravel stack). For a Laravel codebase, the decision it actually supports is "do not adopt as-is; evaluate a port or an internal build."
• Eliminating form/schema duplication (build vs. buy): if the product currently maintains form structure twice — Symfony Form types on the server and hand-written JSON Schema or React/Vue form definitions on the client — Liform converts the server-side form definition into JSON Schema, making the Symfony Form the single source of truth. That is a concrete, measurable saving: one definition instead of two, and no drift when validation rules change. "Buy" here means a small MIT-licensed dependency; the alternative "build" is a bespoke exporter.
• Headless / decoupled frontend roadmap: enables client-side rendering through JSON-Schema-driven renderers (react-jsonschema-form, liform-react, liform-vue, form builders), letting the frontend team ship forms without waiting on backend template changes. This directly supports a roadmap decision to decouple form rendering from server templates.
• API contract publication: a JSON Schema artifact per form can be published alongside API docs so integrators understand field types, required fields, and allowed values without reading PHP. Decide whether schema is the published contract or a derived internal artifact — that choice determines how much spec-compliance rigor you need.
• Low-code / dynamic form capability: if the roadmap includes admin-configurable forms or per-tenant field sets, generating schema from form definitions is a prerequisite capability. Treat this package as a cheap way to validate that capability early, not as the strategy itself.
• Not a platform decision driver: the package is small (141 stars), has zero listed dependents, and a modest opportunity score (~36). Treat it as a tactical utility behind an internal abstraction, never a platform bet.

When to Consider This Package

Adopt or pilot when all of these hold:

• The backend is Symfony with meaningful investment in symfony/form — not a thin or legacy form layer.
• You have a concrete second consumer of the form structure: a JS frontend, a partner integration, a docs portal, or a form builder. Not a hypothetical one.
• Your forms use standard field types and common constraints. Liform's mapping covers the mainstream well and is thin at the edges — custom form types, exotic constraints, conditional/dynamic validation.
• You accept maintenance risk: near-single-maintainer project, low star count, no downstream dependents to surface bugs, and releases that track Symfony majors on the maintainer's schedule (last release March 2025). Budget for the real possibility of forking or patching in-house.
• The value you need is schema generation only — you are not asking it to render forms, validate on the client, or replace OpenAPI tooling.

Look elsewhere when:

• You are on Laravel. There is no direct port. The reusable asset is the limenius/liform core (pure PHP, emits portable JSON Schema); the bundle's DI wiring, config tree, and Twig helpers are Symfony-specific and not reusable. The Laravel equivalent source of truth is FormRequest rules plus Validator, so the generator would need to be rewritten against Laravel's rule set — estimate that as a small internal build (roughly 2–4 weeks for a solid v1 covering common rules), not an adoption. Pulling symfony/form into a Laravel app purely to feed the generator is an anti-pattern worth avoiding.
• You need contract-grade JSON Schema — full draft compliance, $ref composition across models, precise oneOf/anyOf from polymorphic forms. Verify against your trickiest form (nested collections, conditional required fields, custom constraints) before committing; this is exactly where generators leak.
• You need OpenAPI, not JSON Schema. NelmioApiDocBundle or API Platform already own that surface, and running both creates two sources of contract truth.
• You are on or moving to API Platform, which generates schema from resources; form-derived schema becomes an overlapping, competing mechanism.
• Your forms are largely custom form types — the translation layer becomes your own code anyway, so the bundle adds little beyond a starting point.
• Spec drift is unmanaged. JSON Schema draft-04 is the historical default; draft-06/07/2020-12 differ on exclusiveMinimum, $defs vs definitions, and nullable-vs-type-unions. Pin the draft explicitly as config rather than relying on the generator default.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed utility that turns existing server-side form definitions into JSON Schema, so the frontend can render forms from a machine-readable contract instead of a second, hand-maintained copy. The upside is eliminating a whole class of "the client form and the server validation disagree" bugs and shortening the loop for adding or changing fields — one definition, one place to change it. License cost is zero; integration effort is low for a Symfony service. The risks are scope and maintenance: it is a Symfony bundle, not a Laravel package, so it does not apply to our Laravel codebase without a rewrite; and it is a niche project with a single dominant maintainer and no meaningful downstream ecosystem. Recommendation: a time-boxed pilot behind our own thin abstraction on one non-critical form, structured so we can swap or fork if it stalls — not a platform commitment. If the target codebase is Laravel, the decision is instead to scope an internal build against Laravel's validator.

To engineering: One integration point — take a Symfony Form type, emit JSON Schema, publish or serve it. Put it behind an internal interface so removal later is a one-file change. On Laravel, spike for one week with limenius/liform plus symfony/form in a scratch branch to isolate whether the generator's output shape is right from whether a port is cheap; if the output quality is marginal, stop, because the port cost is not justified. If it is right, port a Laravel-native ValidationRuleSet → SchemaObject generator with an explicit handler per rule and a registry that fails loudly on unmapped rules rather than silently dropping them, then lock it down with snapshot/golden-file tests so schema changes surface as diffs in review. Generate schemas at build time (artisan schema:dump) rather than per-request — schemas are deterministic, so scaling becomes a non-issue. Pin the JSON Schema draft, decide the nullable convention once (absence from required plus a ["string","null"] type union) and test it, and use Liform's collection handling as a reference for recursive array-rule walking. Validate the mapping against our three most complex forms before committing.