English for Valibot Developers

Valibot conversations often start as a comparison to Zod, so the vocabulary needs to cover bundle-size arguments alongside the schema-composition concepts both libraries share, so teams can evaluate the trade-off on its actual merits.

Key Vocabulary

Tree-shakeable schema — Valibot’s design where each validation function is a separate import, so a bundler only includes the specific validators a project actually uses, unlike a monolithic schema object. “Because every validator is a tree-shakeable schema function, our bundle only includes the six validators we actually call, not the entire library.”

Pipe composition — Valibot’s pattern of chaining validation and transformation steps as a sequence of functions passed to a pipe, rather than method-chaining on a schema object. “Pipe composition makes this validation explicit — you can see string, then trim, then minLength as a literal sequence, rather than hidden behind chained methods.”

Schema inference — deriving a static TypeScript type directly from a Valibot schema definition, so the runtime validation and the compile-time type never drift apart. “We stopped maintaining a separate interface for this payload — schema inference generates the TypeScript type directly from the Valibot schema.”

Parse versus safeParse — the distinction between a validation call that throws on failure and one that returns a result object, mirroring the same distinction developers already know from Zod. “Use safeParse here instead of parse — we want to handle the validation failure gracefully in the API response, not have it throw.”

Bundle footprint — the actual size a validation library adds to a shipped application after tree-shaking, the primary practical argument for choosing Valibot in size-sensitive frontend contexts. “The bundle footprint difference only matters here because this is a client-side form validator shipped to every visitor — on the backend it wouldn’t move the needle.”

Common Phrases

• “Is this actually using a tree-shakeable schema correctly, or did we import the whole validator namespace by mistake?”
• “Should we use pipe composition here, or is a simpler single validator enough for this field?”
• “Are we relying on schema inference for this type, or is there a manually maintained interface that could drift out of sync?”
• “Should this call use parse or safeParse, given how we want to handle a validation failure here?”
• “Does the bundle footprint difference actually matter for this specific use case, or is it a backend-only path?”

Example Sentences

Justifying a library choice to the team: “We’re picking Valibot for the client-side form validators specifically because of bundle footprint — on the server it genuinely wouldn’t matter which library we used.”

Reviewing a schema definition: “Use schema inference here instead of maintaining a parallel TypeScript interface — that’s exactly the kind of drift this pattern is meant to prevent.”

Debugging an unhandled error: “This crashed because we called parse instead of safeParse — switch it so a bad payload returns a result we can handle instead of throwing.”

Professional Tips

• Lead with bundle footprint when proposing Valibot for client-facing code — it’s the concrete, measurable argument, distinct from taste or preference.
• Use tree-shakeable schema to explain why importing the whole namespace defeats the size benefit — it’s a common mistake worth flagging in review.
• Rely on schema inference instead of hand-written types wherever possible — it removes an entire category of type-drift bugs.
• Be explicit about parse versus safeParse in every validation call reviewed — the choice determines whether a bad payload throws or degrades gracefully.

Practice Exercise

1. Explain why a tree-shakeable schema library can produce a smaller bundle than one with a single large schema object.
2. Describe the difference between parse and safeParse and when you’d choose each.
3. Write a sentence justifying Valibot over a heavier validation library specifically for a client-side bundle.