Liform Laravel Package

Product Decisions This Supports

• Decoupled frontend / headless form rendering. Liform establishes Symfony Form classes as the single source of truth for form structure and serializes them to JSON Schema, so React/Vue/Angular clients can render forms dynamically rather than maintaining a parallel set of hand-written form templates. This is a concrete argument for or against investing in a schema-driven frontend architecture.
• Validation rule consolidation. Symfony validation constraints live on the backend today; a JSON Schema export lets the same constraints drive client-side validation, cutting the most common source of "client accepts it, server rejects it" defects and the support cost that follows.
• API contract and documentation generation. JSON Schema is a first-class OpenAPI artifact. If the roadmap includes richer API docs, request-body validation, or a public API program, this is a cheap path to producing machine-readable contracts from code that already exists.
• Dynamic form builders and low-code/admin tooling. Any product surface where administrators configure forms at runtime (intake forms, surveys, internal CRUD screens) needs a schema layer. This package represents the "derive schema from existing backend model code" approach versus building a bespoke form-definition DSL.
• Build vs. buy vs. fork. With zero stars and zero dependents, the real decision is rarely "adopt this library" — it is "is form-to-schema generation worth building, and is this repo a useful starting point or reference implementation?" It is small, MIT-licensed, and readable, which lowers the cost of vendoring or forking.

When to Consider This Package

Consider it when all of the following hold:

• You are already on Symfony/PHP and Symfony Forms are the established abstraction for the relevant screens — the package provides no value if forms are defined elsewhere.
• You need JSON Schema specifically (not just a REST payload), because you are feeding a schema-driven frontend, a form builder, or an OpenAPI pipeline.
• The use case is internal tooling, a prototype, or a scoped capability where a small, thinly adopted library is acceptable — not a system-critical path with a long support horizon.

Look elsewhere, or budget to fork and own it, when:

• Maintenance risk is unacceptable. No stars, no dependents, no downstream usage is a vendor-risk signal, not a quality verdict. Assume no upstream support, no security response, and no compatibility guarantees across Symfony major versions. Treat any adoption as taking on maintenance.
• You need a stable public standard. If the schema output feeds external partners or a published API, prefer generating from an OpenAPI spec (e.g., NelmioApiDocBundle output) or a maintained schema library, so the contract is decoupled from a single unmaintained renderer.
• You are not on Symfony Forms, or your forms are client-authored — schema-first libraries (react-jsonschema-form and equivalents) invert the direction and fit better.
• Coverage is insufficient. Verify the Symfony field types and constraints your product actually uses (collections, nested types, conditional visibility, custom constraints) are rendered correctly before committing; gaps here turn into hand-maintained patches.

How to Pitch It (Stakeholders)

To executives: This is a small open-source utility that could remove duplicated effort between backend and frontend teams by generating form definitions and validation rules automatically from code we already write. The upside is faster iteration on forms and fewer client/server validation mismatches. The caveat is maturity: the project has no meaningful adoption, so we should treat it as a reference implementation we would own, not a supported dependency. Recommendation: fund a short spike to confirm coverage against our top form types, and only proceed if we are comfortable maintaining a small forked library.

To engineering: Liform maps Symfony Form types and constraints to JSON Schema, giving us one source of truth for form structure and validation. Integration cost is low (MIT, small surface area), and it is straightforward to vendor or fork. The trade-offs are an unmaintained upstream, uncertain coverage for custom field types and nested collections, and no guaranteed Symfony-version compatibility. Proposal: timeboxed evaluation against our real form inventory, with a decision gate on forking and adding tests before it touches a production path.