Liform Bundle Laravel Package

Technical Evaluation

Architecture fit — poor as packaged. survos/liform-bundle is a Symfony bundle, not a Laravel package. Its value is largely in dependency-injection wiring: a bundle class, a DI extension, and a config tree that registers Liform services into the Symfony container. Laravel has no bundle registration concept — there is no AppKernel, no services.yaml compiled container in that sense — so the bundle's primary artifact is inert in a Laravel application. The actual capability (transforming Symfony Form definitions into JSON Schema) lives in the underlying Liform library and the Symfony Form component, not in the bundle wrapper. That means a Laravel integration would mean importing symfony/form plus the core transformer as standalone libraries and discarding the bundle.

Integration feasibility — feasible only by bypassing the package. Pulling symfony/form into Laravel is technically legal (it needs OptionsResolver, EventDispatcher, PropertyAccess, Validator, HttpFoundation — all Composer-installable and Laravel-compatible in isolation). A service provider could construct the form factory and the schema transformer directly. This is a supported Composer path but an unsupported architectural path: you would carry a second form system alongside Laravel's validation/request stack, with two sources of truth for field definitions.

Technical risk — high relative to payoff. Signals: 1 star, 0 dependents, single-maintainer org, no observable downstream usage. That profile implies no external upgrade pressure, no security-response channel, and no bug reports being triaged. The bundle is also almost certainly pinned to older Symfony major versions; each Laravel upgrade that moves PHP forward adds a compatibility break nobody else is fixing. The MIT license is the one unambiguously favorable factor — it permits forking or vendoring the transformer logic outright.

Key questions to close before any commitment

• Does the bundle contain transformation logic beyond container wiring? If not, the package is irrelevant and only the upstream library matters.
• What are the composer.json constraints on php, symfony/form, and the Liform core version, and are they satisfiable on our current PHP/Laravel baseline?
• Which JSON Schema draft does the output target (draft-04 vs 2020-12), and does that match the front-end consumer (e.g. react-jsonschema-form vs a modern validator)?
• Is the upstream Liform library itself maintained, or is this fork downstream of an abandoned original?
• What is the actual business need — runtime dynamic form rendering, or API contract/documentation generation? The second has stronger, better-maintained Laravel-native answers.

Integration Approach

Stack fit — mismatch at the framework layer, partial match at the problem layer. If the requirement is "emit JSON Schema from our field definitions," Laravel already has healthier routes: dedoc/scramble for OpenAPI 3.1 (JSON-Schema-aligned) generated from FormRequests, spatie/laravel-data for typed DTOs with TypeScript/contract generation, or a thin in-house mapper from rules() arrays to JSON Schema property nodes. All three keep the dependency graph inside the Laravel ecosystem.

Migration path, if we proceed. Do not composer require the bundle. Instead: (1) spike the core Liform transformer against symfony/form built standalone in a service provider; (2) express one real form as a Symfony FormType and capture the emitted schema; (3) compare that output against what a Laravel-native mapper produces from the equivalent FormRequest. This converts the decision from "adopt a package" to "port ~200 lines of transformer" — which the MIT license explicitly allows, and which removes the bundle entirely from the long-term dependency surface.

Compatibility. Budget for symfony/form version pinning to conflict-check against Laravel's own Symfony components (HttpFoundation, Finder, Console, VarDumper are already in the vendor tree via the framework). A version skew here causes Composer solver deadlock or, worse, a silently resolved mismatch that breaks at runtime.

Sequencing. Week 1: read the bundle source and upstream library, answer the key questions, produce a one-page build-vs-port-vs-native recommendation. Week 2: parallel spikes — port path and native-mapper path — each against the same form, judged on schema fidelity and lines of owned code. Week 3: decision gate. Do not start with a production integration; the adoption signal is too weak to justify sunk-cost momentum.

Operational Impact

Maintenance — we become the maintainer. With zero dependents and one star, there is no community to absorb upgrades, no issue triage, and no realistic expectation of a security patch. Realistically this is a vendored fork from day one; the honest line item is "small permanent ownership cost," not "free dependency."

Support. None beyond reading source. On-call engineers debugging a schema-generation failure will be reverse-engineering a form component they did not choose, in an idiom (Symfony Form events, data transforms, form type extensions) that is rare on Laravel teams. That is the dominant hidden cost — not the code, the institutional knowledge.

Scaling. Schema generation is CPU-cheap and pure; the sensible posture is compile-time or cached generation keyed by form-definition hash, not per-request generation. If we cache, the failure surface is cache invalidation on form-definition change, which is tractable. Runtime generation on a hot path would add latency for no benefit.

Failure modes to plan for. Recursive or nested form types producing unbounded schema depth; custom form types with no schema mapping silently degrading to permissive {}; PHP deprecation noise from an unpinned Symfony major; Composer conflicts on the next Laravel upgrade forcing an emergency port. Each is survivable but only if the schema layer is isolated behind our own interface so it can be swapped without touching call sites.

Ramp-up. Two to three days for a mid-level engineer to become productive on the ported transformer; closer to a week to become trustworthy on Symfony Form internals and JSON Schema draft semantics. That is a real cost against a benefit we can likely obtain from an actively maintained Laravel-native package.

Recommendation. Conditional no-go on adopting the package; proceed only as a short, time-boxed spike to harvest the transformer logic under MIT. Default to a Laravel-native schema-generation path unless the spike shows the Liform output has a specific fidelity (nested field handling, UI-schema hints) that would cost materially more to reproduce. The package's 1-star, 0-dependent profile means the decision is about owning code we can read in an afternoon — treat it as a build-vs-buy where buy is not really on the table.