数字キーに関する注意

は数値キータイプを受け入れることができ、TypeScriptの組み込みレコードタイプは ですが、ZodでTypeScriptタイプを表すことは困難です。

z.record(keyType, valueType)

Record<KeyType, ValueType>

Record<number, any>

結局のところ、TypeScriptの動作は少し直感的ではありません。

[k: number]

const testMap: { [k: number]: string } = {
  1: "one",
};

for (const key in testMap) {
  console.log(`${key}: ${typeof key}`);
}
// prints: `1: string`

ご覧のとおり、JavaScript はすべてのオブジェクトキーを内部で文字列に自動的にキャストします。Zodは静的型とランタイム型の間のギャップを埋めようとしているので、ランタイムJavaScriptには数値キーのようなものがないため、数値キーを使用してレコードスキーマを作成する方法を提供することは意味がありません。

マップ

const stringNumberMap = z.map(z.string(), z.number());

type StringNumberMap = z.infer<typeof stringNumberMap>;
// type StringNumberMap = Map<string, number>

設定

const numberSet = z.set(z.number());
type NumberSet = z.infer<typeof numberSet>;
// type NumberSet = Set<number>

セットスキーマは、次のユーティリティメソッドでさらに制約できます。

z.set(z.string()).nonempty(); // must contain at least one item
z.set(z.string()).min(5); // must contain 5 or more items
z.set(z.string()).max(5); // must contain 5 or fewer items
z.set(z.string()).size(5); // must contain 5 items exactly

交差点

交差は、"論理 AND" 型を作成する場合に便利です。これは、2 つのオブジェクト タイプを交差させる場合に便利です。

const Person = z.object({
  name: z.string(),
});

const Employee = z.object({
  role: z.string(),
});

const EmployedPerson = z.intersection(Person, Employee);

// equivalent to:
const EmployedPerson = Person.and(Employee);

Though in many cases, it is recommended to use to merge two objects. The method returns a new instance, whereas returns a less useful instance that lacks common object methods like and .

A.merge(B)

.merge

ZodObject

A.and(B)

ZodIntersection

pick

omit

const a = z.union([z.number(), z.string()]);
const b = z.union([z.number(), z.boolean()]);
const c = z.intersection(a, b);

type c = z.infer<typeof c>; // => number

Recursive types

You can define a recursive schema in Zod, but because of a limitation of TypeScript, their type can't be statically inferred. Instead you'll need to define the type definition manually, and provide it to Zod as a "type hint".

interface Category {
  name: string;
  subcategories: Category[];
}

// cast to z.ZodType<Category>
const Category: z.ZodType<Category> = z.lazy(() =>
  z.object({
    name: z.string(),
    subcategories: z.array(Category),
  })
);

Category.parse({
  name: "People",
  subcategories: [
    {
      name: "Politicians",
      subcategories: [{ name: "Presidents", subcategories: [] }],
    },
  ],
}); // passes

Unfortunately this code is a bit duplicative, since you're declaring the types twice: once in the interface and again in the Zod definition.

JSON type

If you want to validate any JSON value, you can use the snippet below.

const literalSchema = z.union([z.string(), z.number(), z.boolean(), z.null()]);
type Literal = z.infer<typeof literalSchema>;
type Json = Literal | { [key: string]: Json } | Json[];
const jsonSchema: z.ZodType<Json> = z.lazy(() =>
  z.union([literalSchema, z.array(jsonSchema), z.record(jsonSchema)])
);

jsonSchema.parse(data);

Thanks to ggoodman for suggesting this.

Cyclical objects

Despite supporting recursive schemas, passing cyclical data into Zod will cause an infinite loop.

Promises

const numberPromise = z.promise(z.number());

"Parsing" works a little differently with promise schemas. Validation happens in two parts:

1. Zod synchronously checks that the input is an instance of Promise (i.e. an object with and methods.).

   .then

   .catch

2. Zod uses to attach an additional validation step onto the existing Promise. You'll have to use on the returned Promise to handle validation failures.

   .then

   .catch

numberPromise.parse("tuna");
// ZodError: Non-Promise type: string

numberPromise.parse(Promise.resolve("tuna"));
// => Promise<number>

const test = async () => {
  await numberPromise.parse(Promise.resolve("tuna"));
  // ZodError: Non-number type: string

  await numberPromise.parse(Promise.resolve(3.14));
  // => 3.14
};

Instanceof

You can use to check that the input is an instance of a class. This is useful to validate inputs against classes that are exported from third-party libraries.

z.instanceof

class Test {
  name: string;
}

const TestSchema = z.instanceof(Test);

const blob: any = "whatever";
TestSchema.parse(new Test()); // passes
TestSchema.parse("blob"); // throws

Functions

Zod also lets you define "function schemas". This makes it easy to validate the inputs and outputs of a function without intermixing your validation code and "business logic".

You can create a function schema with .

z.function(args, returnType)

const myFunction = z.function();

type myFunction = z.infer<typeof myFunction>;
// => ()=>unknown

Define inputs and outputs.

const myFunction = z
  .function()
  .args(z.string(), z.number()) // accepts an arbitrary number of arguments
  .returns(z.boolean());

type myFunction = z.infer<typeof myFunction>;
// => (arg0: string, arg1: number)=>boolean

Function schemas have an method which accepts a function and returns a new function that automatically validates its inputs and outputs.

.implement()

const trimmedLength = z
  .function()
  .args(z.string()) // accepts an arbitrary number of arguments
  .returns(z.number())
  .implement((x) => {
    // TypeScript knows x is a string!
    return x.trim().length;
  });

trimmedLength("sandwich"); // => 8
trimmedLength(" asdf "); // => 4

If you only care about validating inputs, just don't call the method. The output type will be inferred from the implementation.

.returns()

You can use the special option if your function doesn't return anything. This will let Zod properly infer the type of void-returning functions. (Void-returning functions actually return undefined.)

z.void()

const myFunction = z
  .function()
  .args(z.string())
  .implement((arg) => {
    return [arg.length];
  });

myFunction; // (arg: string)=>number[]

Extract the input and output schemas from a function schema.

myFunction.parameters();
// => ZodTuple<[ZodString, ZodNumber]>

myFunction.returnType();
// => ZodBoolean

Preprocess

Zod now supports primitive coercion without the need for . See the coercion docs for more information.

.preprocess()

Typically Zod operates under a "parse then transform" paradigm. Zod validates the input first, then passes it through a chain of transformation functions. (For more information about transforms, read the .transform docs.)

But sometimes you want to apply some transform to the input before parsing happens. A common use case: type coercion. Zod enables this with the .

z.preprocess()

const castToString = z.preprocess((val) => String(val), z.string());

This returns a instance. is a wrapper class that contains all logic pertaining to preprocessing, refinements, and transforms.

ZodEffects

ZodEffects

Custom schemas

You can create a Zod schema for any TypeScript type by using . This is useful for creating schemas for types that are not supported by Zod out of the box, such as template string literals.

z.custom()

const px = z.custom<`${number}px`>((val) => /^\d+px$/.test(val));
px.parse("100px"); // pass
px.parse("100vw"); // fail

If you don't provide a validation function, Zod will allow any value. This can be dangerous!

z.custom<{ arg: string }>(); // performs no validation

Schema methods

All Zod schemas contain certain methods.

.parse

.parse(data: unknown): T

Given any Zod schema, you can call its method to check is valid. If it is, a value is returned with full type information! Otherwise, an error is thrown.

.parse

data

IMPORTANT: The value returned by is a deep clone of the variable you passed in.

.parse

const stringSchema = z.string();

stringSchema.parse("fish"); // => returns "fish"
stringSchema.parse(12); // throws Error('Non-string type: number');

.parseAsync

.parseAsync(data:unknown): Promise<T>

If you use asynchronous refinements or transforms (more on those later), you'll need to use

.parseAsync

const stringSchema1 = z.string().refine(async (val) => val.length < 20);
const value1 = await stringSchema.parseAsync("hello"); // => hello

const stringSchema2 = z.string().refine(async (val) => val.length > 20);
const value2 = await stringSchema.parseAsync("hello"); // => throws

.safeParse

.safeParse(data:unknown): { success: true; data: T; } | { success: false; error: ZodError; }

If you don't want Zod to throw errors when validation fails, use . This method returns an object containing either the successfully parsed data or a ZodError instance containing detailed information about the validation problems.

.safeParse

stringSchema.safeParse(12);
// => { success: false; error: ZodError }

stringSchema.safeParse("billie");
// => { success: true; data: 'billie' }

The result is a discriminated union so you can handle errors very conveniently:

const result = stringSchema.safeParse("billie");
if (!result.success) {
  // handle error then return
  result.error;
} else {
  // do something
  result.data;
}

.safeParseAsync

Alias:

.spa

An asynchronous version of .

safeParse

await stringSchema.safeParseAsync("billie");

For convenience, this has been aliased to :

.spa

await stringSchema.spa("billie");

.refine

.refine(validator: (data:T)=>any, params?: RefineParams)

Zod lets you provide custom validation logic via refinements. (For advanced features like creating multiple issues and customizing error codes, see

.superRefine

Zod was designed to mirror TypeScript as closely as possible. But there are many so-called "refinement types" you may wish to check for that can't be represented in TypeScript's type system. For instance: checking that a number is an integer or that a string is a valid email address.

For example, you can define a custom validation check on any Zod schema with :

.refine

const myString = z.string().refine((val) => val.length <= 255, {
  message: "String can't be more than 255 characters",
});

⚠️ Refinement functions should not throw. Instead they should return a falsy value to signal failure.

Arguments

As you can see, takes two arguments.

.refine

1. The first is the validation function. This function takes one input (of type — the inferred type of the schema) and returns . Any truthy value will pass validation. (Prior to zod@1.6.2 the validation function had to return a boolean.)

   T

   any

2. The second argument accepts some options. You can use this to customize certain error-handling behavior:

type RefineParams = {
  // override error message
  message?: string;

  // appended to error path
  path?: (string | number)[];

  // params object you can use to customize message
  // in error map
  params?: object;
};

For advanced cases, the second argument can also be a function that returns

RefineParams

const longString = z.string().refine(
  (val) => val.length > 10,
  (val) => ({ message: `${val} is not more than 10 characters` })
);

Customize error path

const passwordForm = z
  .object({
    password: z.string(),
    confirm: z.string(),
  })
  .refine((data) => data.password === data.confirm, {
    message: "Passwords don't match",
    path: ["confirm"], // path of error
  });

passwordForm.parse({ password: "asdf", confirm: "qwer" });

Because you provided a parameter, the resulting error will be:

path

ZodError {
  issues: [{
    "code": "custom",
    "path": [ "confirm" ],
    "message": "Passwords don't match"
  }]
}

Asynchronous refinements

Refinements can also be async:

const userId = z.string().refine(async (id) => {
  // verify that ID exists in database
  return true;
});

⚠️ If you use async refinements, you must use the method to parse data! Otherwise Zod will throw an error.

.parseAsync

Relationship to transforms

Transforms and refinements can be interleaved:

z.string()
  .transform((val) => val.length)
  .refine((val) => val > 25);

.superRefine

The method is actually syntactic sugar atop a more versatile (and verbose) method called . Here's an example:

.refine

superRefine

const Strings = z.array(z.string()).superRefine((val, ctx) => {
  if (val.length > 3) {
    ctx.addIssue({
      code: z.ZodIssueCode.too_big,
      maximum: 3,
      type: "array",
      inclusive: true,
      message: "Too many items 😡",
    });
  }

  if (val.length !== new Set(val).size) {
    ctx.addIssue({
      code: z.ZodIssueCode.custom,
      message: `No duplicates allowed.`,
    });
  }
});

You can add as many issues as you like. If is not called during the execution of the function, validation passes.

ctx.addIssue

Normally refinements always create issues with a error code, but with you can create any issue of any code. Each issue code is described in detail in the Error Handling guide: ERROR_HANDLING.md.

ZodIssueCode.custom

superRefine

Abort early

By default, parsing will continue even after a refinement check fails. For instance, if you chain together multiple refinements, they will all be executed. However, it may be desirable to abort early to prevent later refinements from being executed. To achieve this, pass the flag to and return .

fatal

ctx.addIssue

z.NEVER

const schema = z.number().superRefine((val, ctx) => {
  if (val < 10) {
    ctx.addIssue({
      code: z.ZodIssueCode.custom,
      message: "should be >= 10",
      fatal: true,
    });

    return z.NEVER;
  }

  if (val !== 12) {
    ctx.addIssue({
      code: z.ZodIssueCode.custom,
      message: "should be twelve",
    });
  }
});

Type refinements

If you provide a type predicate to or , the resulting type will be narrowed down to your predicate's type. This is useful if you are mixing multiple chained refinements and transformations:

.refine()

superRefine()

const schema = z
  .object({
    first: z.string(),
    second: z.number(),
  })
  .nullable()
  .superRefine((arg, ctx): arg is { first: string; second: number } => {
    if (!arg) {
      ctx.addIssue({
        code: z.ZodIssueCode.custom, // customize your issue
        message: "object should exist",
      });
      return false;
    }
    return true;
  })
  // here, TS knows that arg is not null
  .refine((arg) => arg.first === "bob", "`first` is not `bob`!");

⚠️ You must still call if using with a type predicate function. Otherwise the refinement won't be validated.

ctx.addIssue()

superRefine()

.transform

To transform data after parsing, use the method.

transform

const stringToNumber = z.string().transform((val) => val.length);

stringToNumber.parse("string"); // => 6

Chaining order

Note that above is an instance of the subclass. It is NOT an instance of . If you want to use the built-in methods of (e.g. ) you must apply those methods before any transforms.

stringToNumber

ZodEffects

ZodString

ZodString

.email()

const emailToDomain = z
  .string()
  .email()
  .transform((val) => val.split("@")[1]);

emailToDomain.parse("colinhacks@example.com"); // => example.com

Validating during transform

The method can simultaneously validate and transform the value. This is often simpler and less duplicative than chaining and .

.transform

refine

validate

As with , the transform function receives a object with a method that can be used to register validation issues.

.superRefine

ctx

addIssue

const Strings = z.string().transform((val, ctx) => {
  const parsed = parseInt(val);
  if (isNaN(parsed)) {
    ctx.addIssue({
      code: z.ZodIssueCode.custom,
      message: "Not a number",
    });

    // This is a special symbol you can use to
    // return early from the transform function.
    // It has type `never` so it does not affect the
    // inferred return type.
    return z.NEVER;
  }
  return parsed;
});

Relationship to refinements

Transforms and refinements can be interleaved. These will be executed in the order they are declared.

const nameToGreeting = z
  .string()
  .transform((val) => val.toUpperCase())
  .refine((val) => val.length > 15)
  .transform((val) => `Hello ${val}`)
  .refine((val) => val.indexOf("!") === -1);

Async transforms

Transforms can also be async.

const IdToUser = z
  .string()
  .uuid()
  .transform(async (id) => {
    return await getUserById(id);
  });

⚠️ If your schema contains asynchronous transforms, you must use .parseAsync() or .safeParseAsync() to parse data. Otherwise Zod will throw an error.

.default

You can use transforms to implement the concept of "default values" in Zod.

const stringWithDefault = z.string().default("tuna");

stringWithDefault.parse(undefined); // => "tuna"

Optionally, you can pass a function into that will be re-executed whenever a default value needs to be generated:

.default

const numberWithRandomDefault = z.number().default(Math.random);

numberWithRandomDefault.parse(undefined); // => 0.4413456736055323
numberWithRandomDefault.parse(undefined); // => 0.1871840107401901
numberWithRandomDefault.parse(undefined); // => 0.7223408162401552

Conceptually, this is how Zod processes default values:

1. If the input is , the default value is returned

   undefined

2. Otherwise, the data is parsed using the base schema

.catch

Use to provide a "catch value" to be returned in the event of a parsing error.

.catch()

const numberWithCatch = z.number().catch(42);

numberWithCatch.parse(5); // => 5
numberWithCatch.parse("tuna"); // => 42

Optionally, you can pass a function into that will be re-executed whenever a default value needs to be generated:

.catch

const numberWithRandomCatch = z.number().catch(Math.random);

numberWithRandomDefault.parse("sup"); // => 0.4413456736055323
numberWithRandomDefault.parse("sup"); // => 0.1871840107401901
numberWithRandomDefault.parse("sup"); // => 0.7223408162401552

Conceptually, this is how Zod processes "catch values":

1. The data is parsed using the base schema
2. If the parsing fails, the "catch value" is returned

.optional

A convenience method that returns an optional version of a schema.

const optionalString = z.string().optional(); // string | undefined

// equivalent to
z.optional(z.string());

.nullable

A convenience method that returns a nullable version of a schema.

const nullableString = z.string().nullable(); // string | null

// equivalent to
z.nullable(z.string());

.nullish

A convenience method that returns a "nullish" version of a schema. Nullish schemas will accept both and . Read more about the concept of "nullish" in the TypeScript 3.7 release notes.

undefined

null

const nullishString = z.string().nullish(); // string | null | undefined

// equivalent to
z.string().optional().nullable();

.array

A convenience method that returns an array schema for the given type:

const stringArray = z.string().array(); // string[]

// equivalent to
z.array(z.string());

.promise

A convenience method for promise types:

const stringPromise = z.string().promise(); // Promise<string>

// equivalent to
z.promise(z.string());

.or

A convenience method for union types.

const stringOrNumber = z.string().or(z.number()); // string | number

// equivalent to
z.union([z.string(), z.number()]);

.and

A convenience method for creating intersection types.

const nameAndAge = z
  .object({ name: z.string() })
  .and(z.object({ age: z.number() })); // { name: string } & { age: number }

// equivalent to
z.intersection(z.object({ name: z.string() }), z.object({ age: z.number() }));

.brand

.brand<T>() => ZodBranded<this, B>

TypeScript's type system is structural, which means that any two types that are structurally equivalent are considered the same.

type Cat = { name: string };
type Dog = { name: string };

const petCat = (cat: Cat) => {};
const fido: Dog = { name: "fido" };
petCat(fido); // works fine

In some cases, its can be desirable to simulate nominal typing inside TypeScript. For instance, you may wish to write a function that only accepts an input that has been validated by Zod. This can be achieved with branded types (AKA opaque types).

const Cat = z.object({ name: z.string() }).brand<"Cat">();
type Cat = z.infer<typeof Cat>;

const petCat = (cat: Cat) => {};

// this works
const simba = Cat.parse({ name: "simba" });
petCat(simba);

// this doesn't
petCat({ name: "fido" });

Under the hood, this works by attaching a "brand" to the inferred type using an intersection type. This way, plain/unbranded data structures are no longer assignable to the inferred type of the schema.

const Cat = z.object({ name: z.string() }).brand<"Cat">();
type Cat = z.infer<typeof Cat>;
// {name: string} & {[symbol]: "Cat"}

Note that branded types do not affect the runtime result of . It is a static-only construct.

.parse

Guides and concepts

Type inference

You can extract the TypeScript type of any schema with .

z.infer<typeof mySchema>

const A = z.string();
type A = z.infer<typeof A>; // string

const u: A = 12; // TypeError
const u: A = "asdf"; // compiles

What about transforms?

In reality each Zod schema internally tracks two types: an input and an output. For most schemas (e.g. ) these two are the same. But once you add transforms into the mix, these two values can diverge. For instance has an input of and an output of .

z.string()

z.string().transform(val => val.length)

string

number

You can separately extract the input and output types like so:

const stringToNumber = z.string().transform((val) => val.length);

// ⚠️ Important: z.infer returns the OUTPUT type!
type input = z.input<typeof stringToNumber>; // string
type output = z.output<typeof stringToNumber>; // number

// equivalent to z.output!
type inferred = z.infer<typeof stringToNumber>; // number

Writing generic functions

When attempting to write a function that accepts a Zod schema as an input, it's common to try something like this:

function makeSchemaOptional<T>(schema: z.ZodType<T>) {
  return schema.optional();
}

This approach has some issues. The variable in this function is typed as an instance of , which is an abstract class that all Zod schemas inherit from. This approach loses type information, namely which subclass the input actually is.

schema

ZodType

const arg = makeSchemaOptional(z.string());
arg.unwrap();

A better approach is for the generic parameter to refer to the schema as a whole.

function makeSchemaOptional<T extends z.ZodTypeAny>(schema: T) {
  return schema.optional();
}

ZodTypeAny

is just a shorthand for , a type that is broad enough to match any Zod schema.

ZodType<any, any, any>

As you can see, is now fully and properly typed.

schema

const arg = makeSchemaOptional(z.string());
arg.unwrap(); // ZodString

Constraining allowable inputs

The class has three generic parameters.

ZodType

class ZodType<
  Output = any,
  Def extends ZodTypeDef = ZodTypeDef,
  Input = Output
> { ... }

By constraining these in your generic input, you can limit what schemas are allowable as inputs to your function:

function makeSchemaOptional<T extends z.ZodType<string>>(schema: T) {
  return schema.optional();
}

makeSchemaOptional(z.string());
// works fine

makeSchemaOptional(z.number());
// Error: 'ZodNumber' is not assignable to parameter of type 'ZodType<string, ZodTypeDef, string>'

Error handling

Zod provides a subclass of Error called . ZodErrors contain an array containing detailed information about the validation problems.

ZodError

issues

const data = z
  .object({
    name: z.string(),
  })
  .safeParse({ name: 12 });

if (!data.success) {
  data.error.issues;
  /* [
      {
        "code": "invalid_type",
        "expected": "string",
        "received": "number",
        "path": [ "name" ],
        "message": "Expected string, received number"
      }
  ] */
}

For detailed information about the possible error codes and how to customize error messages, check out the dedicated error handling guide: ERROR_HANDLING.md

Zod's error reporting emphasizes completeness and correctness. If you are looking to present a useful error message to the end user, you should either override Zod's error messages using an error map (described in detail in the Error Handling guide) or use a third party library like

zod-validation-error

Error formatting

You can use the method to convert this error into a nested object.

.format()

const data = z
  .object({
    name: z.string(),
  })
  .safeParse({ name: 12 });

if (!data.success) {
  const formatted = data.error.format();
  /* {
    name: { _errors: [ 'Expected string, received number' ] }
  } */

  formatted.name?._errors;
  // => ["Expected string, received number"]
}

Comparison

There are a handful of other widely-used validation libraries, but all of them have certain design limitations that make for a non-ideal developer experience.

Joi

https://github.com/hapijs/joi

Doesn't support static type inference 😕

Yup

https://github.com/jquense/yup

Yup is a full-featured library that was implemented first in vanilla JS, and later rewritten in TypeScript.

• Supports casting and transforms
• All object fields are optional by default
• Missing object methods: (partial, deepPartial)

• Missing promise schemas
• Missing function schemas
• Missing union & intersection schemas

io-ts

https://github.com/gcanti/io-ts

io-ts is an excellent library by gcanti. The API of io-ts heavily inspired the design of Zod.

In our experience, io-ts prioritizes functional programming purity over developer experience in many cases. This is a valid and admirable design goal, but it makes io-ts particularly hard to integrate into an existing codebase with a more procedural or object-oriented bias. For instance, consider how to define an object with optional properties in io-ts:

import * as t from "io-ts";

const A = t.type({
  foo: t.string,
});

const B = t.partial({
  bar: t.number,
});

const C = t.intersection([A, B]);

type C = t.TypeOf<typeof C>;
// returns { foo: string; bar?: number | undefined }

You must define the required and optional props in separate object validators, pass the optionals through (which marks all properties as optional), then combine them with .

t.partial

t.intersection

Consider the equivalent in Zod:

const C = z.object({
  foo: z.string(),
  bar: z.number().optional(),
});

type C = z.infer<typeof C>;
// returns { foo: string; bar?: number | undefined }

This more declarative API makes schema definitions vastly more concise.

io-ts

fp-ts

fp-ts

fp-ts

• Supports codecs with serialization & deserialization transforms
• Supports branded types
• Supports advanced functional programming, higher-kinded types, compatibility

  fp-ts

• Missing object methods: (pick, omit, partial, deepPartial, merge, extend)
• Missing nonempty arrays with proper typing (

  [T, ...T[]]

  )
• Missing promise schemas
• Missing function schemas

Runtypes

https://github.com/pelotom/runtypes

型推論のサポートは良好ですが、オブジェクト型のマスキングのオプションが制限されています (、などはありません)。sはサポートされていません(それらはZodと同等です)。それらはブランド化された型と読み取り専用型をサポートしていますが、Zodはサポートしていません。

.pick

.omit

.extend

Record

Record

object

• 「パターンマッチング」をサポート:共用体に分散する計算プロパティ
• 読み取り専用型をサポート
• 欠落しているオブジェクトメソッド:(ディープパーシャル、マージ)
• 適切な型指定で空でない配列がありません (

  [T, ...T[]]

  )
• 約束スキーマの欠落
• エラーのカスタマイズがありません

おお

https://github.com/sindresorhus/ow

Owは関数入力の検証に重点を置いています。これは、複雑なアサートステートメントを簡単に表現できるライブラリですが、型指定されていないデータを解析することはできません。それらははるかに多様なタイプをサポートしています。Zod は TypeScript の型システムとほぼ 1 対 1 のマッピングを持っていますが、ow ではいくつかの非常に特殊な型をすぐに検証できます (例: 、彼らのREADMEの完全なリストを参照してください)。

int32Array

関数の入力を検証する場合は、Zod の関数スキーマを使用してください。これは、関数型宣言を繰り返すことなく再利用できる、はるかに単純なアプローチです(つまり、すべての関数の先頭に一連のowアサーションをコピーして貼り付けます)。また、Zodでは戻り値の型も検証できるため、ダウンストリームに渡される予期しないデータがないことを確認できます。

変更履歴

CHANGELOG.md で変更ログを見る