Liform Bundle Laravel Package

Getting Started

This is a Symfony bundle, not a Laravel package — so the honest "getting started" for a Laravel developer is: you will not drop this into a Laravel app. You either (a) run it inside a small Symfony service/microservice that Laravel calls over HTTP, or (b) pull in limen/liform directly with Symfony Forms compiled into a standalone kernel.

Minimal steps for the Symfony side:

composer require survos/liform-bundle

• Flex auto-registers the bundle; otherwise add it to config/bundles.php.
• Verify the bundle's service is autowirable (typically the Liform transformer / form-to-schema service). If container compilation complains about a missing class, check the bundle's Resources/config for the service id and register it explicitly.
• First use case: take an existing Symfony FormType (a ContactType, UserType, etc.) and emit its JSON Schema:

public function schema(FormInterface $form, LiformService $liform): JsonResponse
{
    $schema = $liform->transform($form); // returns an array/object
    return $this->json($schema);
}

The output is a JSON Schema document describing fields, types, required keys, and (partially) constraints. Consume it with react-jsonschema-form, @rjsf/core, jsonforms, or similar.

Where to look first: the bundle is thin — read limen/liform (the actual transformer) since that's where the behavior lives. The bundle is mostly wiring.

Implementation Patterns

Schema-as-API-contract. Expose GET /forms/{type}/schema from Symfony. Laravel calls this, caches the payload, and hands the schema to a front-end renderer. This is the only pattern that makes sense given the stack mismatch.

Reuse admin/CRUD forms as the source of truth. If your team already maintains Symfony AbstractType classes for back-office CRUD, Liform turns them into renderable schema for free. This is the strongest value proposition: one definition, two consumers (server validation + client form rendering).

Schema + submit endpoint pairing. The generated schema only describes shape. Pair it with:

• Symfony Form submission for server-side validation ($form->submit($request->request->all())),
• The schema for client-side pre-validation UX only.

Microservice bridge. Run a minimal Symfony app with just Forms + Liform. From Laravel:

$schema = Cache::remember("form.{$type}.schema", 3600, fn () =>
    Http::get("http://forms-service/schema/{$type}")->json()
);

Schemas are deterministic per FormType + config, so cache aggressively and bust on form change.

Integration tips:

• Register a dedicated route and controller rather than a catch-all — keeps the schema endpoint discoverable.
• Version the endpoint (/v1/schema/{type}) since schema shape changes are breaking for clients.
• If you must keep everything in one app, use Symfony Forms standalone: composer require symfony/form symfony/validator symfony/event-dispatcher. You will recreate a chunk of the container that Laravel does not provide.

Gotchas and Tips

• The framework mismatch is the pitfall. Symfony Forms need EventDispatcherInterface, OptionsResolver, Validator, and HttpFoundation in scope. Laravel's container won't satisfy them. Budget for a bridge/standalone kernel before you promise anything.
• Draft/version drift. Liform emits a particular JSON Schema draft; client libraries (AJV versions, react-jsonschema-form forks) differ in what they accept. Pin your client renderer against a captured sample schema before building UI on top.
• Constraints don't fully round-trip. Not every Symfony Constraint (custom validators, callback constraints, expression language) surfaces as a JSON Schema keyword. Treat the schema as structural, not a complete validation spec. Keep server-side validation authoritative.
• CollectionType, file uploads, and nested types produce nested object/array schemas. Verify these explicitly; nested form handling is the usual place generated schemas get thin or surprising.
• Data transformers are invisible. A form type that maps a string to an entity on submit still validates as a string. Don't infer submit logic from the schema.
• Extension points: Liform supports transform listeners / custom transformers for adding metadata (descriptions, enums, widgets). If the bundle doesn't expose config for them, extend the underlying Liform transformer rather than forking the bundle.
• Debugging: dump the raw schema array (dd()) before JSON-encoding. If a field is missing, check the FormType's buildForm — unmapped or dynamically-added fields won't appear until the form is built.
• Maintenance risk. 1 star, 0 dependents, tiny surface area. Prefer depending on limen/liform directly and treat this bundle as a thin, optionally-vendored wrapper. Pin the version; the bundle's value is only service registration you can replicate in ~20 lines.
• Debug config quirks: if autowiring fails, the bundle may register its service with a specific id — inject by id or alias it in services.yaml rather than fighting the container.