Valibot's creator proposes a redesign of the library's API ahead of its v1 release, replacing the current pipeline argument approach with a new pipe function. The change addresses pain points like non-modular pipelines increasing bundle size, confusing nesting when combining transform and brand methods, and limited control over input/output types. The post lays out code comparisons of old vs new syntax, advantages (smaller bundle size, type transformation support, a future metadata feature), disadvantages (more verbose code for medium schemas, potential nested pipelines), and invites community feedback on naming and design before finalizing the v1 API.
Questions this post answers
How does Valibot's proposed pipe function differ from the current pipeline argument syntax?
The pipe function takes a schema as its first argument followed by validation, transformation, or branding actions, replacing the array-based pipeline argument like string([toTrimmed(), email()]) with pipe(string(), toTrimmed(), email()). Unlike the current pipeline, pipe also supports changing the data type mid-chain, letting transform and brand live inside the pipeline instead of wrapping the schema, which reduces function nesting and simplifies the schemas, methods, and actions mental model. Developers weighing a Valibot API migration can track how libraries evolve their validation patterns on daily.dev.
Why does Valibot's current pipeline implementation increase bundle size for simple schemas?
The current pipeline implementation is not modular, which adds over 200 bytes to the bundle size of a simple string schema, accounting for almost 30% of that schema's total size. Because the pipeline logic is bundled even when unused features aren't needed, the design forces extra overhead onto minimal schemas that don't require validations or transformations. Bundle-size tradeoffs in validation libraries are the kind of detail teams compare on daily.dev before picking a tool.