@talosjs/validation component is a type-safe validation layer built on ArkType, TypeScript’s 1:1 runtime validator. You describe the shape of your data once with Assert({...}), and the same schema both narrows your TypeScript types and validates values at runtime. The package provides Assert, scope, union, and intersection, adds a set of ready-made constraints (email, URL, port, country code, and more), and exposes an abstract Validation class for building your own reusable validators. When a schema is attached to a route, the framework runs it for you before the controller is reached.
What the validation layer gives you
AnAssert({...}) definition does two jobs at once: it is a runtime validator and a static TypeScript type, so there are no duplicate interfaces to keep in sync. The syntax is string-based and compact — it is ArkType’s definition syntax, so anything ArkType understands works here. Assert, scope, union, and intersection cover expressions like string.email, number >= 0, 'a' | 'b', and optional keys marked with ?.
When a schema is attached to a route as params, queries, or payload, the framework runs it before the controller, and an invalid request produces an error response on its own. A set of ready-made constraints covers the shapes you hit most often (email, URL, port, hostname, locale, currency, country code, hex color, names, IDs), so you aren’t re-writing the same rules. For anything those don’t cover, extend the abstract Validation class with getConstraint and getErrorMessage to package a rule and its message as a reusable class.
How it works
A schema is a function. Calling it with data returns either the validated value or anAssert.errors object. The Validation class wraps that flow into a { isValid, message } result, and the routing layer applies your schemas to incoming requests automatically.
Defining schemas
UseAssert to describe an object. Each value is a schema expression: a primitive, a constrained primitive, a numeric range, a literal union, or an array. Mark a key optional by suffixing it with ?.
scope and export() the result; combine schemas with union and intersection.
Validation in routing
The most common place you use validation is on a route. Pass schemas to@Route.http and the framework validates the request before your controller’s index runs, so inside the controller the data is already guaranteed to match.
paramsvalidates path parameters (e.g.:idin the path).queriesvalidates the query string.payloadvalidates the request body.
Built-in constraints
Import these from@talosjs/validation/constraints. Each is a Validation subclass: construct it and call validate(data) to get a { isValid, message? } result.
Custom validators
To package a rule of your own, extend the abstractValidation class. It requires two methods and gives you validate for free.
validate(data, constraint?) calls the schema; on failure it returns your getErrorMessage() (falling back to the schema’s summary), otherwise { isValid: true }.
Inline assertions and utilities
Assert builds a schema you can call immediately to check a value, which is handy for one-off assertions without defining a named schema.
jsonSchemaToTypeString(schema) converts a JSON Schema object into a readable TypeScript-style type string, handling primitives, arrays, objects with required/optional keys, and anyOf/oneOf/allOf unions and intersections. Pair it with a schema’s toJsonSchema() for documentation or AI-output descriptions.
Types
AssertType: alias for the schemaType; the return type ofgetConstraintand the type of any schema.IAssert: the interface implemented by every validator (getConstraint,getErrorMessage, andvalidate).ValidationResultType: the result ofvalidate,{ isValid: boolean; message?: string }.
Getting the most from schemas
Attach schemas to@Route.http (params, queries, payload) so bad input is rejected before any business logic runs. Export a schema once and reuse it for routing, custom validators, and JSON Schema generation rather than re-describing the same shape in several places. Reach for AssertEmail, AssertPort, and the other ready-made constraints before writing your own, and extend Validation only for rules that genuinely don’t exist yet.
When you do write a custom rule, return a clear getErrorMessage() so a failure explains what was expected instead of leaning on the raw summary. Mark optional fields with the ? key suffix so the static type and the runtime check stay in agreement.
See Routing, Request, Response, and Entity for the surfaces that consume these schemas.