Liform Bundle Laravel Package

Product Decisions This Supports

• API-first / contract-first design: Liform's core value is turning Symfony Forms (already a declarative schema) into JSON Schema, so a single source of truth can drive both server-side validation and client-side validation (React/Angular/Vue forms, dynamic form rendering, JSON Schema validators like AJV).
• Reducing duplicated validation logic: Front-end and back-end teams stop hand-maintaining parallel field rules (required, types, enums, min/max). This is a real maintenance-cost and consistency decision, not a niche feature.
• Documentation and tooling: Generated schemas can feed API docs, form builders, admin UIs, and mock-data generators — a leverage point for internal tooling and developer experience.
• Decision to evaluate — not adopt blindly: This specific package is a low-signal artifact: 0 stars, 0 dependents, score 0. Treat it as a candidate implementation of an idea, not a production dependency. The capability (Symfony Forms → JSON Schema) is legitimate; this package is the wrong vehicle. Decisions it should drive: "Do we need schema export at all?" (feature/roadmap), "Do we take on a third-party dependency to get it?" (build vs. buy), and "If so, do we use the upstream/established implementation?"

When to Consider This Package

Consider the underlying approach only when:

• You are already fully invested in Symfony Forms as your model/form layer and cannot easily move to annotations/attributes or a dedicated schema library.
• You need JSON Schema output for a real consumer (dynamic front-end forms, validation parity, external API contracts).
• You can afford to vendor/fork the code and own its maintenance.

Look elsewhere — and you almost certainly should here — when:

• Maintenance risk is material. Zero stars, zero dependents, no ecosystem signal, and a fork-style namespace (RogerDS/LiformBundle) strongly suggest a personal fork of the upstream limenius/liform-bundle. Buying this means betting on an individual, not a community.
• You need current Symfony/Laravel/PHP support. Such packages frequently lag framework versions and go unpatched; check the last commit date, test suite, and CI before anything else.
• You have a supported alternative. Prefer the upstream limenius/liform-bundle if it meets version constraints, or compose with symfony/serializer/symfony/form metadata plus a JSON Schema library (e.g., opis/json-schema) that you control. For Laravel specifically, this is not a natural fit — laravel-json-schema-style or hand-rolled metadata is less risk than pulling a Symfony bundle into a Laravel app.
• You cannot isolate it. If it isn't confined behind an interface you own, an unmaintained bundle is a future incident.

Verdict: validate the need; do not adopt this artifact without a hard evidence check (release history, issue activity, PHPUnit coverage, last release date, fork relationship to upstream).

How to Pitch It (Stakeholders)

To executives: "We've identified a capability — automatically generating API JSON Schemas from our existing form definitions — that removes duplicated validation logic and speeds up front-end work. The concept is sound and worth a small discovery spike. However, the specific package surfaced is a zero-star, zero-dependency fork with no community backing, which signals maintenance risk. We are not recommending adopting it as-is; we recommend a 2–3 day evaluation against the established upstream project or a small in-house implementation. Low cost, contained scope, clear decision point."

To engineering: "This is a Symfony Forms → JSON Schema bridge. The idea gives us one source of truth for validation across server and client. The specific package is a personal fork with no traction, so we should treat it as reference code, not a dependency. Before writing it off, check: does the upstream limenius/liform-bundle still fit our Symfony/PHP versions? Is the output schema stable enough to use as a contract? If yes, use upstream. If no, budget a small internal adapter behind our own interface so we're not locked in. Worst case, it's a one-sprint spike; best case, it deletes a recurring source of front-end/back-end drift."