form-create-designer: a Vue low-code form designer for Element Plus, Ant Design Vue and Vant

What form-create-designer actually produces

The project is a drag-and-drop canvas that outputs FormCreate rules as JSON. That is the whole product boundary. The README lists the characteristics in one line each: generate forms from JSON data, extend with custom components, more than 40 built-in form and layout components, a set of form operation APIs, sub-forms and grouping, event configuration, style configuration, table layout, validation, multi-language forms, and an AI form assistant.

The audience is Vue developers building internal tooling where forms are the main workload: government systems, OA, ERP, e-commerce and workflow systems, according to the repository description. In those settings a form is rarely a one-off page. It is a schema that gets edited, versioned and rendered in several places. A designer that emits JSON fits that shape better than a page builder that emits a Vue file, because the JSON can be stored, diffed and re-rendered by a runtime you control.

The trade-off is that the designer is only half the problem. The README documents how to mount the component and what it renders. It does not document a persistence contract: no schema version field, no migration story for rules saved under an older release. If your forms are long-lived, that gap is yours to close.

Three packages, three UI frameworks, one repository

The repository is a pnpm and lerna monorepo. The top level holds pnpm-workspace.yaml, lerna.json, tsconfig.json and a packages directory, and the root package.json is marked private with scripts that fan out per package: dev:ele, dev:vant and dev:antd each run lerna against a single scope, while build runs lerna run build across all of them.

The packages map to UI frameworks rather than to features. @form-create/designer is built on @form-create/element-ui and ElementPlus and supports Vue 2 and Vue 3. @form-create/antd-designer is built on @form-create/ant-design-vue and AntDesignVue and supports Vue 3. @form-create/vant-designer is built on @form-create/vant and Vant, targets mobile, and supports Vue 3.

That split is the architecture. The designer component depends on a matching form-create runtime for the same UI library, and the README makes you install both: the designer package plus the runtime package plus the UI library itself. Nothing is bundled for you. If you install the Element Plus designer against an Ant Design Vue runtime, you have not misconfigured a flag, you have picked the wrong pair. The mobile package is the clearest case: its npm install line pulls in @form-create/vant-designer, @form-create/element-ui, @form-create/vant, element-plus and vant together, because the mobile designer still needs Element Plus present.

Installing the Element Plus designer and mounting it

The README gives a Node install path and a CDN path. The Node path is the one that matters for an application. Install the designer, the matching runtime and the UI library:

npm install @form-create/designer@next
npm install @form-create/element-ui@next
npm install element-plus

Then register all three on the app. The designer exposes both itself and the form-create runtime, so FcDesigner.formCreate is registered as a second plugin:

import FcDesigner from '@form-create/designer'
import ELEMENT from 'element-plus';
import 'element-plus/dist/index.css';

app.use(ELEMENT);
app.use(FcDesigner)
app.use(FcDesigner.formCreate)

With the plugins registered, the designer is a single tag. The README's usage example is exactly this, with a ref so you can reach the component instance later:

<fc-designer ref="designer"/>

What you should see is the designer canvas: a component palette, a drag target and a properties panel, with the 40-plus built-in components available for placement. The Ant Design Vue package follows the same three-step shape with @form-create/antd-designer, @form-create/ant-design-vue and ant-design-vue, and the same <fc-designer> tag. The mobile package uses <fc-designer-mobile> instead.

The README stops at mounting. It does not show how to read the generated JSON back out of the ref, how to load an existing rule set into the canvas, or how to register a custom component. Those APIs exist in the wider FormCreate documentation linked from the header, not in this repository's README, and that is the first thing to budget for.

Where the designer is the wrong tool

If you need a form service rather than a form component, this is the wrong layer. There is no server here. The repository is a set of front-end packages; storing submissions, handling uploads, enforcing server-side validation and controlling who may edit which form are all outside it. A team expecting a hosted builder with a submission inbox will spend its first week discovering that the JSON is the deliverable and everything after it is their code.

The second boundary is the framework. Every package is Vue. The README's install examples are Vue plugin registrations and Vue single-file-component tags. There is no React, Svelte or framework-agnostic build described, and the primary language of the repository is Vue. If your application shell is not Vue, the designer cannot be dropped into it.

The third is version pinning. Every README install command carries the @next dist-tag, including the CDN script URLs. That is the branch the project develops on, and the default branch is next. Pinning to a moving tag means an install can pull a different release than the one you tested. For a form designer whose output is persisted JSON, that is a risk worth removing by pinning an explicit version in your lockfile rather than trusting the tag in a build script.

How it compares with Avue and Variant Form

The closest alternatives people search for alongside this project are Avue form design and Variant Form. The difference is in what the designer emits and what it assumes about the rest of your stack.

Avue's form designer is part of a larger Avue component and CRUD framework built on Element Plus. Adopting it usually means adopting Avue's conventions for tables, columns and configuration objects, and its designer is one surface of that system. form-create-designer is narrower: it produces FormCreate rules and depends on a form-create runtime, and the repository ships three parallel packages so the same designer concept exists over Element Plus, Ant Design Vue and Vant. If you already use Avue for your tables, its designer keeps one configuration model across the app. If you do not, form-create-designer asks you to adopt less.

Variant Form is a Vue 3 form designer that also works from a JSON schema and offers a designer component and a rendered form component, with a commercial tier for advanced features. The practical difference for a decision is where the schema is defined and how much of the product is open. form-create-designer's packages are MIT licensed and the repository is public, and the AI form assistant is separately open sourced at xaboy/form-create-assistant, which the README links and describes as generating and modifying FormCreate rules from natural language. If generating rules from a prompt is part of your plan, that separate repository is the thing to evaluate, not the designer itself.

Maintenance, licence and what an upgrade costs

The repository is not archived, and the last push was on 2026-08-09. The release history shows v3.5.0 on 2026-06-02, v3.4.0 on 2025-11-22 with the AI form assistant, and v3.3.1 on 2025-09-05. That is a cadence of a few releases a year, with the most recent one a few months before the last commit. Judge the project on that rhythm rather than on any claim about how actively it is developed.

The licence is MIT, declared in both the README badge and the root package.json, with copyright held by xaboy from 2021. MIT is permissive: you can use the packages in commercial and closed-source products, and you keep your own code. The obligation that matters in practice is retaining the copyright and permission notice in distributions. That is a description of the licence text, not legal advice; your own counsel decides what your distribution requires.

The upgrade cost is concentrated in the JSON. The designer's output is the interface between your application and the library, and the README does not describe a schema version or a migration path between releases. A patch bump that changes how a component serialises its props can change the rules you already stored. The cheap insurance is to keep a fixture: a form you build in the designer, its JSON checked into the repository, and a test that renders it after each upgrade. That test is the only thing that will tell you whether v3.5.0 reads rules written by v3.4.0.

Editorial conclusion

Adopt form-create-designer if your stack is already Vue with Element Plus, Ant Design Vue or Vant, and you want the designer to live inside your own admin UI rather than in a separate SaaS. Do not adopt it if you need a hosted form service, a non-Vue runtime, or a designer whose persistence layer is documented: the README describes the component and its JSON output, not where you store that JSON or how you version it. Before committing, verify three things in a scratch project: that @form-create/designer@next installs cleanly against your Vue and Element Plus versions, that the JSON a test form produces round-trips through your own backend, and that the custom component you need can be registered through the extension mechanism the README mentions but does not demonstrate.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. xaboy/form-create-designer on GitHub