The version number in a YAML file is not decorative. YAML 1.1 and YAML 1.2 disagree on what several common strings mean, and the disagreement is silent: a file that parses one way under a 1.1 parser produces different data under a 1.2 parser. The most consequential difference is the boolean set. YAML 1.1 treats…
JSON and YAML are not competitors at the boundary; they are dialects of the same data model. YAML 1.2 was designed so that every valid JSON document is also valid YAML . The conversion between them is therefore a transformation of syntax, not semantics. But the syntax carries information that the other format cannot express:…
YAML’s expressive power is its attack surface. A parser that can instantiate language objects from tags will do so when the document contains the right tag, and an attacker who controls the document controls what gets instantiated. The result is remote code execution from what looks like a configuration file. This is not a theoretical…
YAML’s type system is not built into the syntax; it is built into the tags. A tag is a URI that identifies the type of a node. When a plain scalar is written without a tag, the parser applies a schema—a set of resolution rules—to decide whether true is a boolean, 2001-12-14 is a timestamp…
YAML’s DRY (Don’t Repeat Yourself) features let you define a block of configuration once and reuse it in multiple places. An anchor (&) marks a node with a name; an alias (*) references that node elsewhere; a merge key (<<) inserts the entries of one mapping into another. Together they eliminate duplicated configuration in large…
Arrays and tuples are Zod’s collection schemas. z.array(schema) validates that every element matches the same schema, and infers T[]. z.tuple([a, b]) validates a fixed-length sequence where each position has its own schema, and infers a positional tuple type like [string, number]. The distinction is structural: arrays are homogeneous and variable-length; tuples are heterogeneous and fixed-length….
An object schema is the primary constructor for structured data in Zod. It takes a shape—an object whose values are schemas—and returns a schema whose inferred type mirrors that shape. The behavior on unknown keys, however, is not uniform: Zod objects strip unknown keys by default, reject them when constructed with z.strictObject(), or preserve them…
Zod v4 promotes string-format validators from chained methods to top-level functions. The v3 syntax z.string().email() still parses in v4 but is deprecated and emits warnings in tooling; the canonical v4 form is z.email() . The change is not cosmetic. Top-level functions return dedicated schema types with optimized validation and compose more cleanly than the chained…
Zod’s primitive schemas are the atoms from which every larger schema is built. z.string(), z.number(), z.boolean(), and z.date() each produce a schema whose runtime validator checks the JavaScript type and whose inferred TypeScript type is the corresponding primitive. On their own, these schemas accept any value of that type. Constraints—.min(), .max(), .email(), .int()—narrow the accepted…
A Zod schema is a runtime value and a type declaration at the same time. z.infer<> is the bridge between them: it reads a schema’s TypeScript type and returns it as a type alias. The schema is the source of truth, and the type is derived from it, never written beside it. This is the…