Liform Bundle Laravel Package

Product Decisions This Supports

• Framing correction that shapes every decision below: this is a Symfony bundle, not a Laravel package. The reusable core is the underlying liform/liform library (Symfony Form → JSON Schema), which hard-depends on symfony/form. There is no Laravel applicability as packaged — the bundle layer is Symfony kernel glue (DI definitions, bundle class, Twig helper) with no analogue in a Laravel app. Treat "adopt this package" as "decide whether a Symfony-Form-derived JSON Schema contract is worth standing up Symfony's Form component inside our stack."
• Single source of truth for form shape. Where the same form surface exists as a server-rendered Symfony form and a client-side rendered form (admin panels, onboarding, settings, tenant configuration), deriving JSON Schema from the existing Form type removes a hand-maintained duplicate of field names, types, and a subset of constraints.
• Validation parity (partial, by design). Schema keywords emitted (required, enum, minLength, pattern, numeric bounds) let the frontend run compatible client-side validation and cut round-trips. Caveat for any roadmap built on this: the emitted schema is permissive relative to actual server validation — Validator constraints that liform doesn't map simply don't appear, so the client will accept input the server rejects. Any "reduce invalid submissions" business case must be scoped to the covered subset only.
• API contract and documentation generation. Schema output can feed OpenAPI/components or internal developer docs, reducing drift between the spec and real form behavior.
• Dynamic / config-driven form rendering and low-code roadmap. JSON Schema is native input to react-jsonschema-form, Formily, JSON Forms, and similar. This is the decision this package actually unlocks: if a schema-driven renderer is on the roadmap, a server-side generator becomes a prerequisite. If it isn't, this is a solution without a consumer.
• Build vs. buy. With 0 stars and 0 dependents, there is no "buy" here in any commercial sense — it's a thin MIT adapter and a reference implementation. The realistic decision is build a small internal converter (or go OpenAPI-first) vs. timebox a spike on the pattern. Budget the spike at days, not sprints.

When to Consider This Package

Consider it when:

• You are on Symfony and Symfony Forms is already the canonical form layer — no new paradigm introduced.
• A downstream consumer is already committed to a JSON Schema renderer or doc pipeline. No committed consumer, no business case.
• Your forms are small, static, and use standard field types — coverage of the mapping is genuinely good there.
• You can pin exact versions, commit the lockfile, vendor, or fork. With zero dependents, assume no upstream fixes and no CVE triage; a stale transitive tree is a live concern for anything internet-facing.
• The form catalogue is fixed and enumerated — not generated dynamically from the database.

Look elsewhere (or build a converter) when:

• You are on Laravel or any non-Symfony framework. You'd be reimplementing the concept regardless; a translator from FormRequest rules to JSON Schema, or schema-first authoring validated with opis/json-schema, is cheaper and avoids two form abstractions and two upgrade cadences in one deployable.
• Forms lean on EntityType/ChoiceType with query builders, PRE_SET_DATA/PRE_SUBMIT listeners, collection prototypes, or data transformers — these have no faithful schema representation, and transformers mean the schema describes the transformed shape, not the submitted payload.
• You need bi-directional sync (schema → form) rather than one-way generation.
• You are OpenAPI-first / schema-first — Symfony Forms would be the wrong origin.
• You need vendor support, SLAs, or active security patching, or you would refuse a fork (in which case the maintenance risk is unmitigated).
• Draft compatibility is unverifiable: liform historically tracked draft-04 with partial later support, while modern renderers assume draft-07/2020-12 (if/then, $defs). If the chosen renderer needs those keywords, that alone can kill it.

Sequencing rule regardless of path: keep it off the critical path. Run it as a parallel spike behind an interface (FormSchemaGenerator::for(string $formKey): array) so it is swappable at one seam, and gate broader rollout on a <80% constraint coverage for real forms = abandon threshold plus frontend sign-off that the schema is sufficient to render, including error states (JSON Schema carries no server-side validation messages).

How to Pitch It (Stakeholders)

For executives: This is a small MIT-licensed Symfony utility that converts existing server-side form definitions into JSON Schema — the format modern frontend form renderers and API documentation tools already consume. The concept is sound: one canonical form definition producing both server validation and a client-consumable schema, which would reduce duplication and improve API doc accuracy. Three facts should govern the decision. First, it is Symfony-only and does not fit our Laravel stack — adopting it means installing Symfony's Form component as a subsystem inside Laravel for a serialization feature. Second, adoption signals are effectively zero (0 stars, 0 dependents, agency-published wrapper around another library) — no CVE triage, no community corpus, no guaranteed PHP 8.3+/Symfony 7 release, so we would fork or vendor it and own it. Third, the value is entirely contingent on a schema-driven frontend that may not exist; without a committed consumer, the schema is a nice-to-have. Recommendation: do not adopt as a dependency. Fund a timeboxed spike (1–2 weeks, throwaway) to prove the pattern against 3–5 representative forms and measure real constraint coverage. Kill it if coverage is under 80%; otherwise the durable answer is a small internal Laravel-native converter or an OpenAPI-first contract — either way, keep the whole capability behind one interface so it is swappable.

For engineering: The bundle is thin serializer glue; ignore it and evaluate liform/liform + symfony/form directly. Realistic shape of the work: register a Symfony Form factory manually as a Laravel singleton (do not boot the bundle or a kernel), define a fixed catalogue of plain form types, expose GET /api/schemas/{formKey} with HTTP caching and a schema version field, and add golden-file contract tests per form as the regression net against a dependency we don't control. Expect the abstraction to leak silently wherever runtime state is involved — dynamic choice types, event listeners, data transformers, and unmapped Validator constraints. Ongoing cost is 0.1–0.2 FTE for patching and drift, spiking on any PHP major upgrade, plus a knowledge-concentration hazard: one engineer will understand the Symfony-Form-to-schema translation, and that module becomes a black box when they leave. Pin exact versions, commit the lockfile, and pre-decide whether a fork is acceptable — if it isn't, don't start.