Liform Laravel Package

Product Decisions This Supports

• Schema-first form generation. Liform renders HTML forms directly from JSON Schema, so the same schema can drive API validation, storage shape, and the data-entry UI. That directly supports decisions like "should this form be hand-built in Blade or generated from a contract?" — and favors generated when the schema is already authoritative.
• Build vs. buy (adopt). Writing a JSON-Schema-to-form renderer is a multi-month effort with endless edge cases (nested objects, arrays of objects, $ref, enums, required/optional, defaults). Adopting a package that already maps schema primitives onto Symfony/Laravel form types is almost always cheaper than in-house work — provided the maintenance risk below is acceptable.
• Config-driven product surfaces. Enables features where the customer defines the fields: custom fields on records, tenant-specific intake forms, CMS field editors, survey/questionnaire builders, configuration wizards. The schema becomes product configuration rather than code.
• Contract parity between front end and API. Because validation and rendering derive from the same schema, "the form accepted it but the API rejected it" drift becomes a schema bug rather than two divergent implementations.
• PATCH/partial-update semantics. The v1.1.2 fix ("do not set value for unchecked types") means unchecked checkboxes and boolean fields are no longer coerced into submitted values. For a PM this matters in two concrete scenarios: consent/opt-in checkboxes (where a spurious true is a compliance problem) and partial updates (where an untouched boolean must stay absent, not become false). It is a correctness fix for boolean and multi-select fields, not a cosmetic one.

When to Consider This Package

Adopt when:

• JSON Schema is already the source of truth for your payloads, or you are willing to make it so.
• Forms are predominantly data-entry/admin/tooling surfaces — back offices, internal ops, configuration screens — where server-rendered forms and a schema contract beat bespoke UI polish.
• Your form structures are nested or repetitive (arrays of objects, address blocks, line items) and hand-writing Blade + validation rules per shape is becoming duplicated work.
• You want validation rules derived from the schema rather than maintained in parallel in FormRequest classes.
• You need a small, framework-integrated dependency rather than a JS SPA form stack.

Look elsewhere when:

• Maintenance risk is disqualifying. This project's release cadence is effectively dormant — v1.1.2 dates to June 2021, and this release is a single-line bug fix rather than active feature work. For a product with a multi-year horizon, budget for forking or wrapping it; do not assume upstream will fix your bug. Verify compatibility against your target Laravel/PHP version before committing.
• The UI needs rich client-side interactivity — conditional branching, live validation, drag-and-drop builders. That is the companion JS renderer's territory (or react-jsonschema-form), not this package alone.
• Forms need first-class file uploads, rich text, or design-system-grade accessibility out of the box.
• Your team is committed to Inertia/Livewire/React component libraries and would be fighting two rendering paradigms.
• The schema is trivial and static — a handful of hand-written forms is cheaper than a schema pipeline.

How to Pitch It (Stakeholders)

For executives (one paragraph): Liform lets us generate data-entry screens from JSON Schema instead of hand-coding each one. The business value is speed and consistency: one definition of a form's shape drives the UI, the validation, and the API contract, which removes a whole class of "the form let it through but the backend rejected it" defects and cuts the cost of shipping internal tools and customer-configurable fields. The trade-off is dependency risk — the upstream project is small and has not shipped features since mid-2021 — so we should adopt it behind a thin internal adapter, pin the version, and treat it as vendored code we can maintain ourselves if needed. The v1.1.2 patch fixes boolean/checkbox handling so unchecked fields are no longer submitted with a value, which removes a real correctness hazard for consent checkboxes and partial updates; it is a low-risk, worthwhile upgrade.

For engineering (the ask): Upgrade to v1.1.2 — a one-commit fix ensuring unchecked types do not receive a value, which affects boolean fields, checkboxes, and PATCH-style submissions. Confirm it against our Laravel/PHP versions, pin the tag, and wrap the renderer behind our own service so we retain the option to swap implementations. Treat the package as dormant upstream: any bug we hit becomes ours to fix, so keep the surface area small.