Skip to content

Package Boundaries

FormX uses multiple packages so the core logic, view protocol, framework runtime, and UI skin can evolve independently.

PackageResponsibilityUI dependency
@formxjs/coreSchema, rules, expressions, values, state, validation, resources, diagnostics.No
@formxjs/ui-coreConverts engine state into framework-neutral view models.No
@formxjs/vue-coreVue lifecycle and reactivity adapters.Vue
@formxjs/vue-epVue + Element Plus skin.Vue and Element Plus
@formxjs/vueRecommended Vue entry for applications.Vue packages

Why split packages

Splitting packages keeps @formxjs/core usable in designers, tests, Node.js, and future non-Vue renderers. It also avoids forcing UI dependencies onto users who only need the engine.

Most Vue + Element Plus apps should install:

bash
pnpm add @formxjs/vue vue element-plus

Headless-only usage:

bash
pnpm add @formxjs/core

Custom skin authors usually depend on:

bash
pnpm add @formxjs/core @formxjs/ui-core

Future Package Naming

Future React or custom UI skins should keep the same layering:

ScenarioSuggested packageNotes
React framework adapter@formxjs/react-coreReact hooks, subscriptions, ref handle, and view state.
React + Ant Design skin@formxjs/react-antdRender FieldView with Ant Design components.
Recommended React entry@formxjs/reactApplication-facing entry that aggregates the React adapter and default skin.
Vue + another UI library@formxjs/vue-naive, @formxjs/vue-antdReuse @formxjs/vue-core and replace only the skin.
Internal design system@formxjs/vue-company-ui or @formxjs/react-company-uiReuse Core and UI Core, render with company components.

These packages should not re-implement rules, resources, or validation. Framework packages adapt lifecycle and reactivity; skin packages consume the @formxjs/ui-core view model.