Velite is an MIT-licensed TypeScript tool that turns Markdown, MDX, YAML, JSON, and other files into a type-safe application data layer validated with Zod schemas, aimed at developers building content-driven sites and applications in any JavaScript framework.

What it is

Velite is a build-time content compiler. Content is placed in a content folder, collections are declared as schemas, and the velite command converts those source files into a typed data layer the application reads at runtime. Validation runs through Zod, and Velite generates TypeScript type inference from the same schemas, so the shape that validated the source content is the shape available in application code. Output is emitted as JSON, Entry, and DTS files, described in the README as framework-agnostic and usable from any JavaScript framework or library. The project is written in TypeScript, published under the MIT licence, and maintained by zce.

The concrete problem it solves is the gap between loose content files and typed application code. Without a tool like this, a project hand-writes a loader per source format and manually keeps a TypeScript interface in sync with frontmatter, which drifts as content grows. Velite replaces that bespoke preprocessing script: collection schemas are declared once, and parsing, relative file and image resolution, schema validation, and output generation are handled by the tool. Its topic list explicitly tags it alongside contentlayer, placing it in the same generation of content-to-data-layer tooling that reads local files rather than storing content in a hosted backend.

Key capabilities

• Validates content collections with Zod schemas and generates TypeScript type inference for the resulting data.
• Reads Markdown, MDX, YAML, and JSON out of the box, including relative file and image processing.
• Emits JSON, Entry, and DTS output, described as framework-agnostic with out-of-the-box support for any JavaScript framework or library.
• Customizable input and output directories, plus support for custom loaders and hooks.
• Extends to arbitrary file types through custom loaders, and to custom field validation and transformation through schema context().
• Built on esbuild, per the project topic list, with few runtime dependencies by design.
• Usage flow documented as: move content into content, define collection schemas, run velite, then consume the output data.

Who uses it and how

• The README's "Who's using Velite?" section names Ark UI, Chakra UI, and Park UI as dependent projects.
• zce/taxonomy, a fork of the shadcn-ui/taxonomy project, is offered as a real-world example for starting quickly.
• Next.js teams are supported through a documented guide at velite.js.org/guide/with-nextjs; a first-party plugin package is on the roadmap, and the current integration is a snippet.
• Developers evaluating the tool can run it in the browser on StackBlitz using the velite-basic and velite-nextjs examples.
• Any JavaScript framework or library can consume the emitted JSON, Entry, and DTS output, so adoption is not tied to a single renderer.

Getting started

Define collection schemas over files in a content folder and run the velite command to produce the typed data layer. A browser-based trial is available through the StackBlitz velite-basic and velite-nextjs examples, with guides at velite.js.org.

How it compares

The topic list places Velite alongside contentlayer, the closest named relative in the facts, which puts it in the same category of local-file content compilation rather than hosted content management. Its distinguishing stated properties are Zod-based validation, generated TypeScript inference, and JSON, Entry, and DTS output. The facts name no paid products this project replaces, so no licence or cost comparison against commercial offerings can be drawn from them.

When to use it — and when not to

Velite fits projects that keep content in the repository and want typed, validated access to it without a hosted CMS. The roadmap is candid about maturity gaps: unit and E2E tests, incremental build, a scaffolding tool, and a packaged Next.js plugin are all listed as unfinished, and the repository carries 33 open issues, so teams that need guaranteed test coverage, incremental rebuilds, or a first-party framework plugin should treat those as reasons to wait or to plan around the current snippet-based integration.