Standard Schema

Standard Schema is a common interface designed to be implemented by JavaScript and TypeScript schema libraries.
The goal is to make it easier for ecosystem tools to accept user-defined type validators, without needing to write custom logic or adapters for each supported library. And since Standard Schema is a specification, they can do so with no additional runtime dependencies. Integrate once, validate anywhere.
The spec was designed by the creators of Zod, Valibot, and ArkType. Recent versions of these libraries already implement the spec (see the full list of compatible libraries below).
The specification consists of a single TypeScript interface StandardSchemaV1 to be implemented by any schema library wishing to be spec-compliant.
This interface can be found below in its entirety. Libraries wishing to implement the spec can copy/paste the code block below into their codebase. It's also available at @standard-schema/spec on npm and JSR.
The specification meets a few primary design objectives:
These are the libraries that have already implemented the Standard Schema interface. (If you maintain a library that implements the spec, create a PR to add yourself!)
The following tools accept user-defined schemas conforming to the Standard Schema spec. (If you maintain a tool that supports Standard Schemas, create a PR to add yourself!)
These are the most frequently asked questions about Standard Schema. If your question is not listed, feel free to create an issue.
No. The @standard-schema/spec package is completely optional. You can just copy and paste the types into your project. We guarantee no breaking changes without a major version bump.
If you don't mind additional dependencies, you can add @standard-schema/spec as a dependency and consume it with import type. The @standard-schema/spec package contains no runtime code and only exports types.
Despite being types-only, you should not install @standard-schema/spec as a dev dependency. By accepting Standard Schemas as part of your public API, the Standard Schema interface becomes a part of your library's public API. As such, it must be available whenever/wherever your library gets installed, even in production installs. For this to happen, it must be installed as a regular dependency.
The goal of prefixing the key with ~ is to both avoid conflicts with existing API surfaces and to de-prioritize these keys in auto-complete. The ~ character is one of the few ASCII characters that occurs after A-Za-z0-9 lexicographically, so VS Code puts these suggestions at the bottom of the list.
In TypeScript, using a plain Symbol inline as a key always collapses to a simple symbol type. This would cause conflicts with other schema properties that use symbols.
Unique symbols can also be declared in a "nominal" way that won't collapse. In this case the symbol key is sorted alphabetically in autocomplete according to the symbol's variable name.
Thus, these symbol keys don't get sorted to the bottom of the autocomplete list, unlike tilde-prefixed string keys.
The ~standard.validate() function might return a synchronous value or a Promise. If you only accept synchronous validation, you can simply throw an error if the returned value is an instance of Promise. Libraries are encouraged to preferentially use synchronous validation whenever possible.
by @colinhacks, @fabianhiller, and @ssalbdivad