Liform Bundle Laravel Package

Technical Evaluation

Architecture fit — primary blocker. Despite the framing, webdevcraft/liform-bundle is not a Laravel package. It is a Symfony bundle whose purpose is to wire the limenius/liform library into a Symfony application's DI container so that Symfony\Component\Form\FormInterface instances can be serialized into JSON Schema. Laravel has no bundle/extension concept; the package's actual value-add (service definitions, container tags, configuration tree, optional Twig extension) is inert in a Laravel application. What remains reusable is the upstream limenius/liform transformer plus symfony/form itself — i.e., we would be adopting a Symfony component stack inside Laravel and discarding the bundle wrapper.

Integration feasibility — moderate, but not as a dependency. symfony/form runs standalone and can be installed via Composer alongside Laravel (it needs symfony/event-dispatcher, symfony/options-resolver, symfony/property-access, symfony/validator). A viable path exists: prototype with symfony/form + limenius/liform outside Laravel, then write a thin Laravel service provider that binds Liform\Resolver/Liform\Transformer and exposes a schema-building facade. The bundle itself would be excluded or vendored for reference. That is a build effort, not an install.

Technical risk — high. Signals are unambiguous: 0 stars, 0 dependents, last release 2021-02-18, no ecosystem pull. Effective abandonment means no PHP 8.2+/Symfony 6/7 compatibility work, no JSON Schema draft updates, no CVE response. The largest concrete hazard is transitive version conflict: Laravel 10/11 pin Symfony 6.3/7.x components, while a 2021-era bundle almost certainly constrains Symfony 4.4/5.x — Composer will either refuse to resolve or force us to pin Laravel's own symfony/* packages down, which is a non-starter. Secondary risks: unknown test coverage and CI, undocumented transformer customization surface, and output schema drift being invisible until a client renders the wrong form.

Key questions to resolve before any build.

1. What is the actual consumer — server-driven UI, a form builder, or API contract documentation? The answer determines whether JSON Schema is even the right artifact versus OpenAPI.
2. Which JSON Schema draft must we emit, and does the consumer (e.g., react-jsonschema-form) accept the draft Liform produces?
3. Do we need symfony/form's full type system, or would spatie/laravel-data DTOs plus a schema mapper cover our form definitions with far less dependency surface?
4. What are the PHP and symfony/* version constraints in the package's composer.json, and do they intersect with our target Laravel version?
5. Who owns the fork if we vendor it, and what is the upgrade budget per Laravel major?
6. Is dedoc/scramble (OpenAPI) or an existing schema generator already sufficient for the client's needs?

Integration Approach

Stack fit. Assume Laravel 10/11 on PHP 8.2+. The bundle is a poor fit by construction; symfony/form + limenius/liform installed directly is the only workable shape. Treat the bundle as documentation of how to wire Liform, not as code to require. Do not add it to composer.json; copy the relevant service wiring into an app-level LiformServiceProvider.

Migration path.

1. Standalone spike (1 week): in a scratch directory, install symfony/form, symfony/validator, and limenius/liform; define three representative forms (nested objects, collections, enums/choices); dump schemas and diff against a hand-written expected schema.
2. Adapter (1–2 weeks): Laravel service provider binding the resolver/transformer; a FormSchema facade with ->toJsonSchema(FormClass::class); configuration for draft version and transformer overrides.
3. Form definition layer: decide whether form classes are Symfony AbstractType subclasses (idiomatic for Liform) or generated from a declarative PHP array/DTO. This is the decision with the longest tail.
4. Contract tests: snapshot the emitted schema per form in CI so any form change that alters the schema fails the build — this is the only defense against silent drift.
5. Consumer integration: expose schemas as a cached endpoint or build-time artifact, and validate incoming payloads server-side with opis/json-schema so the generated schema is authoritative rather than decorative.

Compatibility. Enumerate composer.json constraints of the bundle and of limenius/liform before writing a line of adapter code. If either caps symfony/form below what Laravel's own Symfony components require, the path is dead and we fall back to option B. Also verify PHP 8.2/8.3 deprecations, and check whether the Twig extension is needed (skip it — Laravel uses Blade; the schema should be data, not template output).

Sequencing. Spike → go/no-go on dependency resolution → adapter → contract tests → consumer. Run a parallel one-week spike on the fallback (spatie/laravel-data + a JSON Schema mapper, or dedoc/scramble if the real need is API docs) so the go/no-go is comparative rather than absolute.

Operational Impact

Maintenance. This is a fork-ownership commitment, not a dependency. Once adopted, we own: Symfony Form upgrades each Laravel major, Liform transformer patches, JSON Schema draft migrations, and any bug fixes. With zero dependents there is no upstream community to absorb that work. Realistically budget 5–10% of one engineer per quarter, spiking around Laravel majors.

Support. No maintainer responsiveness, no issue tracker activity, no security advisory pipeline. We would be tracking symfony/form and symfony/http-foundation advisories ourselves and patching on our own SLA. For a package that emits contracts consumed by front-end clients, "silent behavioral change on a transitive bump" is a realistic outage vector.

Scaling. Schema generation is CPU-bound reflection over form metadata. It must not run per request in a hot path. Compile schemas at build time or cache aggressively keyed on form class + application version; the output is deterministic, so cache invalidation is cheap. Horizontal scaling is otherwise unremarkable — no state, no external calls.

Failure modes to instrument.

• Schema drift after an unrelated form change (mitigate: CI snapshot tests, diff alerting).
• Composer resolution failure on Laravel/Symfony upgrade, blocking the platform upgrade entirely.
• Consumer rejection of an emitted draft version or unsupported keyword.
• Divergence between the emitted schema and actual server-side validation, letting invalid payloads through or rejecting valid ones.
• Twig extension or container-tag assumptions surfacing only in production.

Ramp-up. Non-trivial. Engineers must learn Symfony Form's type/extension/event model — a genuinely different mental model from Laravel's validators and Blade — plus Liform's transformer customization points and the JSON Schema spec's draft differences. Expect 2–3 weeks before a mid-level engineer is productive and can safely modify a transformer without breaking client contracts. Document the form-definition conventions early; they are the thing new engineers will most often get wrong.

Recommendation. Given a 0-star, 0-dependent, four-year-stale Symfony bundle, the opportunity score of 22.28 is directionally correct: low leverage. Do not adopt the bundle. Use it as a reference for wiring, prototype the underlying limenius/liform + symfony/form combination only if a JSON Schema contract is a hard requirement, and keep the DTO-plus-mapper fallback funded in parallel. If the real goal is API documentation, redirect to an OpenAPI generator and close this out.