Valibot Repository Structure

Monorepo Layout

valibot/
├── library/          # Core valibot package (zero dependencies)
├── packages/
│   ├── i18n/         # Translated error messages (25+ languages)
│   └── to-json-schema/  # JSON Schema converter
├── codemod/
│   ├── migrate-to-v0.31.0/  # Version migration
│   └── zod-to-valibot/      # Zod converter
├── website/          # valibot.dev (Qwik + Vite)
├── brand/            # Brand assets
├── skills/           # Agent skills (this folder)
└── prompts/          # Legacy AI agent guides

Core Library (/library/src/)

Directory Structure

Schema Categories

• •Primitives: string, number, boolean, bigint, date, symbol, blob, file
• •Objects: object, strictObject, looseObject, objectWithRest
• •Arrays: array, tuple, strictTuple, looseTuple, tupleWithRest
• •Advanced: union, variant, intersect, record, map, set, lazy, custom
• •Modifiers: optional, nullable, nullish, nonNullable, nonNullish, nonOptional

Action Types

Validation (return issues): email, url, uuid, regex, minLength, maxValue, check

Transformation (modify data): trim, toLowerCase, toUpperCase, mapItems, transform

Metadata: brand, flavor, metadata, description, title

File Naming Convention

Each schema/action/method has its own directory:

schemas/string/
├── string.ts        # Implementation
├── string.test.ts   # Runtime tests
├── string.test-d.ts # Type tests
└── index.ts         # Re-export

Core Patterns

Schemas define data types:

export interface StringSchema<TMessage> extends BaseSchema<...> {
  readonly kind: 'schema';
  readonly type: 'string';
  // ...
}

Actions validate/transform in pipelines:

export interface EmailAction<TInput, TMessage> extends BaseValidation<...> {
  readonly kind: 'validation';
  readonly type: 'email';
  // ...
}

Methods provide API functions:

export function parse<TSchema>(
  schema: TSchema,
  input: unknown
): InferOutput<TSchema>;

Key Types

• •BaseSchema, BaseValidation, BaseTransformation - Base interfaces
• •InferOutput<T>, InferInput<T>, InferIssue<T> - Type inference
• •Config, ErrorMessage<T>, BaseIssue<T> - Configuration and errors
• •'~standard' property - Standard Schema compatibility

Website (/website/src/routes/)

API Documentation

routes/api/
├── (schemas)/string/     # Schema docs
│   ├── index.mdx         # MDX content
│   └── properties.ts     # Type definitions
├── (actions)/email/      # Action docs
├── (methods)/parse/      # Method docs
├── (types)/StringSchema/ # Type docs
└── menu.md               # Navigation

Guides

routes/guides/
├── (get-started)/       # Intro, installation
├── (main-concepts)/     # Schemas, pipelines, parsing
├── (schemas)/           # Objects, arrays, unions
├── (advanced)/          # Async, i18n, JSON Schema
├── (migration)/         # Version upgrades
└── menu.md              # Navigation

Development

Playground

Use library/playground.ts for quick experimentation.

Adding a Schema/Action

1. •Create directory: library/src/schemas/yourSchema/
2. •Create files: yourSchema.ts, yourSchema.test.ts, yourSchema.test-d.ts, index.ts
3. •Follow existing patterns (copy similar implementation)
4. •Export from category index.ts
5. •Run pnpm -C library test

Modifying Core Types

⚠️ Changes to library/src/types/ affect the entire library. Always run full test suite.

Quick Lookups

Commands

# Library
pnpm -C library build      # Build
pnpm -C library test       # Run tests
pnpm -C library lint       # Lint
pnpm -C library format     # Format

# Website
pnpm -C website dev        # Dev server
pnpm -C website build      # Production build

# Root
pnpm install               # Install all
pnpm format                # Format all

Key Principles

1. •Modularity - Small, focused functions; one per file
2. •Zero dependencies - Core library has no runtime deps
3. •100% test coverage - Required for library
4. •Tree-shakable - Use // @__NO_SIDE_EFFECTS__ annotation
5. •Type-safe - Full TypeScript with strict mode
6. •ESM only - Imports include .ts extensions

Do's and Don'ts

Do:

• •Follow existing code patterns
• •Write runtime and type tests
• •Add JSDoc documentation
• •Keep functions small and focused
• •Check bundle size impact

Don't:

• •Add external dependencies
• •Modify core types without full test run
• •Skip tests
• •Create large multi-purpose functions
• •Modify generated files (dist/, coverage/)