AutoForm Core

The schema-agnostic engine that powers AutoForm's field parsing, validation, and defaults.

Library
npm
v4.0.0
3,491stars
MIT License

Repository Health

Pre-computed score based on development activity, maintenance, community, maturity, and trend momentum.How we score it →
54/100Fair
Development Activity48
Maintenance24
Community52
Maturity52
Momentum40

Technical Analysis

AI-assessed by reading the actual repository — architecture, code quality, innovation, and documentation.How we score it →
72/100Good
Architecture82
Code Quality62
Innovation68
Learning Curve75

@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/ParsedSchema types describing required/optional state, defaults, descriptions, nested object/array schemas, and per-field FieldConfig overrides (label, description, custom wrappers, sort order).
  • Validation and default-value entry points - parseSchema(), validateSchema(), and getDefaultValues() 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() and replaceEmptyValue() recursively normalize empty strings/arrays/objects to undefined/removed, closing the gap between form-library defaults and schema optional() semantics.
  • Automatic label generation - getLabel() derives a human-readable label from field config, schema description, or by beautifying the camelCase field key (e.g. firstNameFirst name).
  • Deterministic field ordering - sortFieldsByOrder() recursively sorts parsed fields (including nested object fields) by an optional numeric order in FieldConfig, 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 ParsedField types 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 SchemaProvider against 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/getDefaultValues directly 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.

Join founders buildingwith open source

Opinionated takes, migration guides, cost-saving tips, and insights from the open source ecosystem.

Subscribe on Substack
Join 750+ subscribers

Search