AutoForm Core
The schema-agnostic engine that powers AutoForm's field parsing, validation, and defaults.
Repository Health
Technical Analysis
@autoform/core is the foundation package of the AutoForm ecosystem — a small, dependency-free library that turns any schema (Zod, Yup, Joi) into a normalized set of typed fields a UI renderer can turn into a form. It defines the SchemaProvider interface that schema-specific packages implement, plus the shared logic every renderer package (React, MUI, shadcn/ui, Mantine, Chakra, Ant Design) calls into: parsing a schema into ParsedField objects, validating submitted values, computing default values, and sorting fields by declared order.
Because core has zero runtime dependencies and no opinion about rendering or validation library, it is the stable contract point in an otherwise fast-moving monorepo — schema adapters and UI adapters can each evolve independently as long as they honor the SchemaProvider interface core exposes. Utility functions like removeEmptyValues and replaceEmptyValue also solve a recurring pain point in form libraries: reconciling empty-string form defaults with schema validators (like Zod’s optional()) that expect undefined.
Most consumers never install @autoform/core directly — it’s a transitive dependency pulled in by @autoform/react, @autoform/zod, @autoform/mui, and similar packages. It’s the right package to reach for directly only when building a custom renderer or a new schema adapter for a validation library AutoForm doesn’t yet support.
What You Get
- SchemaProvider interface - a small, formal contract (
parseSchema,validateSchema,getDefaultValues) that any schema library (Zod, Yup, Joi, or a custom one) can implement to plug into AutoForm. - Typed field model -
ParsedField/ParsedSchematypes describing required/optional state, defaults, descriptions, nested object/array schemas, and per-fieldFieldConfigoverrides (label, description, custom wrappers, sort order). - Validation and default-value entry points -
parseSchema(),validateSchema(), andgetDefaultValues()wrap a schema provider with runtime assertions so renderer packages get a consistent error if a malformed provider is passed in. - Empty-value reconciliation helpers -
removeEmptyValues()andreplaceEmptyValue()recursively normalize empty strings/arrays/objects toundefined/removed, closing the gap between form-library defaults and schemaoptional()semantics. - Automatic label generation -
getLabel()derives a human-readable label from field config, schema description, or by beautifying the camelCase field key (e.g.firstName→First name). - Deterministic field ordering -
sortFieldsByOrder()recursively sorts parsed fields (including nested object fields) by an optional numericorderinFieldConfig, falling back to schema declaration order.
Common Use Cases
- Building a custom AutoForm renderer - a team using a UI library without an official AutoForm package (e.g. a custom design system) implements a thin renderer against core’s
ParsedFieldtypes instead of the official React/MUI/shadcn packages. - Adding a new schema adapter - a contributor wants AutoForm to support a validation library beyond Zod/Yup/Joi and implements
SchemaProvideragainst core’s interface to plug it into the existing renderer ecosystem. - Internal admin panels - an internal tool already has Zod schemas for its API and uses AutoForm (built on core) to auto-generate CRUD forms without hand-writing field-by-field UI.
- Form logic without AutoForm’s React layer - a non-React consumer (or a headless integration) uses core’s
parseSchema/validateSchema/getDefaultValuesdirectly to drive its own custom rendering loop.
Under The Hood
Architecture
Core sits at the bottom of a two-axis plugin architecture: schema adapters (@autoform/zod, @autoform/yup, @autoform/joi) implement its SchemaProvider interface on one axis, while UI renderer adapters (@autoform/react, @autoform/mui, @autoform/shadcn, @autoform/mantine, @autoform/chakra, @autoform/ant) consume its ParsedField/ParsedSchema types and logic functions on the other, with core itself depending on neither. The module (src/index.ts) re-exports four small, single-purpose files — types.ts for the shared data model, schema-provider.ts for the provider contract, logic.ts for parsing/validation/default-value orchestration plus empty-value normalization, and label.ts for label derivation — so changing rendering behavior or adding a schema library never requires touching the others. A schema provider passed to any entry point is runtime-asserted via assertSchemaProvider() before use, giving every downstream package a single, consistent error message for a misconfigured integration.
Tech Stack
Written in TypeScript with zero runtime dependencies, built with tsdown into dual ESM/CJS output (.mjs/.cjs with corresponding .d.mts/.d.cts type declarations) and consumed via workspace-linked exports map entries. It lives inside a Turborepo/pnpm-workspace monorepo alongside its sibling adapter packages, versioned and released together via Changesets, with linting via a shared @autoform/eslint-config package.
Code Quality
No unit or integration test files exist for this package (or the wider monorepo, beyond Cypress end-to-end tests against the demo app in apps/web) — correctness for core’s parsing/validation logic is currently exercised only indirectly through the schema-adapter packages and the e2e suite. Code is fully typed with no implicit any in public signatures, uses small single-responsibility functions, and follows consistent JSDoc-style comments on every exported interface and function, but the absence of direct unit tests is a real gap for a package this foundational.
API Design
The public surface is deliberately minimal — four re-exported modules, a handful of functions, and no configuration object — which keeps the barrier to writing a new schema or renderer adapter low. Function names map directly to form-building concepts (parseSchema, validateSchema, getDefaultValues, getLabel, sortFieldsByOrder) rather than internal implementation details, and the runtime assertion in assertSchemaProvider() surfaces a specific, actionable error message pointing at ZodProvider as a concrete example, which shortens the debugging loop for anyone integrating a new provider incorrectly.