Liform Bundle Laravel Package

Product Decisions This Supports

• Who owns the form definition. The core decision this package enables: let the backend own form structure and validation (Symfony FormTypes) and emit JSON Schema so the frontend renders from a contract rather than hand-maintaining a parallel form tree. That is an architecture call, not a library call, and it should be made deliberately.
• Build vs. buy vs. fork for dynamic forms. The capability — walking a FormType tree and producing a JSON Schema document — is a mapping layer, not a platform. This package is a useful reference implementation for scoping an in-house emitter (likely a few hundred lines plus edge cases for constraints, collections, and nested types).
• Roadmap fit for schema-driven UI. Relevant to any epic involving dynamic questionnaires, onboarding/KYC wizards, admin form builders, config editors, or low-code internal tooling — anywhere a non-engineer or a remote client needs to render a form it did not define.
• API product and documentation decisions. Feeds machine-readable form metadata into API docs, client SDK generation, and contract tests, reducing the recurring defect class of "frontend accepts what backend rejects."
• Platform decision gate. The brief frames this as a Laravel/PHP package; it is a Symfony bundle. If the product is Laravel-first, this is not an adoptable dependency — it is a design reference. Settle the framework question before the library question.

When to Consider This Package

Consider it when:

• The application is Symfony and Symfony Forms are already the source of truth for validation and (server-side) rendering.
• You need machine-readable form metadata for a JS renderer (react-jsonschema-form, Formik, a custom renderer loop), for API documentation, or for generated tests.
• You are willing to vendor or fork it, pin the version, and own the edge cases — the surface area is small enough that this is cheap.
• You want a concrete starting point rather than a blank file for a schema emitter you intend to own anyway.

Look elsewhere when:

• You are on Laravel. There is no adapter here; you would be re-implementing the FormType walk against Laravel validation rules and Blade/Livewire/Inertia components. Use a JSON Schema builder library plus your validation rules instead.
• You need OpenAPI, not JSON Schema. NelmioApiDocBundle or API Platform give you broader, maintained coverage for the API-docs use case.
• You need a supportable dependency. Zero stars, zero dependents, a single maintainer, and no downstream community mean no backstop for security response or framework upgrades. For a revenue-critical flow, that is a hard no without an internal fork owner.
• Your forms aren't Symfony Form types (Filament, Livewire, Inertia, custom builders) — the package has nothing to introspect.

Note on lineage: this is a derivative of the Limenius Liform work. If you want the more-travelled path for the same idea, evaluate upstream first and treat this as an alternative or a modernization.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed utility that lets one team own the definition of a form and have every client render it from a contract. The business value is speed on dynamic-form surfaces — onboarding, wizards, admin tooling — and the removal of a whole class of "the form and the validation disagree" bugs. It is not a strategic platform bet: adoption cost is low and reversal cost is near zero. Fund it as a one-to-two-week spike inside a larger forms initiative, not as a line item.

To engineering: It converts Symfony FormType metadata into JSON Schema so a JS renderer can drive the UI from the backend definition. The code is a mapping layer with a narrow surface, which means vendoring and pinning is straightforward and the fork cost is trivial. The real caveats: bus factor of one, no adoption signal, and no framework-upgrade guarantee — so add characterization tests around the specific forms you depend on and keep the integration behind an interface you control. If the roadmap standardizes on Laravel, stop here: use this as a design reference for an in-house emitter built on your validation rules, and get the same product outcome without the platform mismatch.