Liform Bundle Laravel Package

Product Decisions This Supports

• Form-to-API contract generation. If your product exposes Symfony Forms over an API, this bundle converts those form definitions into JSON Schema, giving you a machine-readable contract for the payload without hand-maintaining a parallel spec. This supports decisions like "do we hand-write JSON Schema for every endpoint, or derive it from the forms we already maintain?"
• Single source of truth for server and client validation. Generating schema from the PHP form means client-side rendering/validation (React JSON Schema Form, JSON Forms, formily) can be driven by the same definition the server enforces. This is the core product argument: one definition, two consumers, less drift.
• Headless / SPA and low-code front ends. If the roadmap includes admin builders, dynamic forms, or a UI that renders arbitrary forms from metadata, JSON Schema is the interchange format. This package is a cheap probe into that architecture before committing to a larger platform investment.
• Roadmap input for a "form platform" initiative. A spike here answers the architecture question early: derive schema from existing Symfony Forms (cheap, coupled to PHP) vs. author schema-first and generate forms from it (more expensive, decoupled).
• Build vs. buy (really: buy vs. vendor). The package is MIT and thin, so the realistic decision is not "adopt a vendor" but "vendor/fork a small wrapper" versus "write ~a day of serialization glue." That reframes the risk calculus: the licensing permits you to absorb the code.

When to Consider This Package

Consider it when all of the following hold:

• You are on Symfony and already invest in Symfony Forms as your form/validation layer. (Note: despite the framing as a Laravel/PHP package, this is a Symfony bundle and is not usable in a Laravel application without reimplementation.)
• You need JSON Schema as an output artifact — for a JS form renderer, API documentation, or client-side validation — and you want it derived from existing form classes rather than authored separately.
• The scope is internal tooling, prototypes, or an admin surface, where a single-maintainer dependency is tolerable.
• You can vendor the code into your repo and treat it as your own, with the upstream repo viewed as a reference implementation.

Look elsewhere (or build in-house) when:

• You are on Laravel or framework-agnostic PHP — hard blocker, no adapter exists.
• You need production-grade maintenance guarantees: 1 star, 0 dependents, and a single maintainer mean effectively no community support, no security response process, and no upgrade path. Treat it as abandoned-by-default.
• Your real requirement is OpenAPI/JSON Schema for API resources — API Platform's schema generation or Symfony's JsonSchema model classes cover that with active maintenance.
• You need schema-first form generation (schema as the source, forms generated from it). This package only goes one direction, form → schema.
• Your forms are complex in ways serializers typically fail on: nested collections with dynamic prototypes, custom data transformers, conditional constraints, or heavy use of PRE_SUBMIT event listeners. Expect to debug and extend the transformation for anything non-trivial.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed Symfony component that turns our existing form definitions into JSON Schema — the format our front-end form libraries already understand. The strategic value is eliminating duplicated form and validation definitions across server and client. However, the project has effectively zero adoption (one star, one maintainer, no dependent projects). The recommendation is not to adopt it as a dependency but to spend one engineering day evaluating it as a reference implementation and, if it fits, vendoring the code into our repository. That caps the downside at a day of effort while answering a real architecture question: do we derive form schemas from our PHP forms, or move to a schema-first form layer?

To engineering: The bundle wraps Liform to serialize Symfony Form types into JSON Schema. It is a one-way transform (form → schema), it is Symfony-only, and it is unmaintained by any meaningful measure. Treat it as a spike, not a dependency. Concretely: (1) run it against two of our most complex real forms, including one with a collection type and one with a custom data transformer; (2) record where the output diverges from what react-jsonschema-form or JSON Forms expects; (3) decide between vendoring a patched copy, lifting the Liform transformation logic directly, or adopting API Platform's JSON Schema generation if our need is resource-shaped rather than form-shaped. The output of the spike is a one-page go/no-go with an effort estimate for the in-house alternative — not a merged dependency.