Confusing terms - parse vs validate

[MartinMuzatko]

I'm still trying to wrap my head around this article that points out that parsing is superior to validating.

Yet, zod coins itself as a validation library, and as far as I can judge, it is one.

Zod is a [...] validation library.

Yet you have chosen to name the method to validate .parse, .safeParse or parseAsync.
If zod were a parser, it could help me to transform data e.g. retrieved by a REST API to be in acceptable shape for a database.

Would it make sense to add an alias for .parse named validate to make usage more intuitive, without including a breaking change?
This is literally the first thing I intuitively tried after defining my first validation schema.

Otherwise, I am curious how you came to the conclusion of how to name the method :)

[scotttrinh]

@MartinMuzatko

Thanks for your feedback here. The following thoughts are my own, but they are the reason I became involved with the Zod project, so hopefully I can provide some context here.

The difference between parsing and validating in this context is that the function returns the data rather than asserting anything about the input data directly. That's the reason we don't have type guards or assertion functions, for instance. Since running the schema's checker on the value doesn't tell TypeScript anything about the input data, I feel like parse is still the more semantically correct name for what Zod is doing.

If zod were a parser, it could help me to transform data e.g. retrieved by a REST API to be in acceptable shape for a database.

That's what transform, refine and the built-in refinements do. A parser consumes some input and returns a more precise, structured output. From the linked article:

Consider: what is a parser? Really, a parser is just a function that consumes less-structured input and produces more-structured output. By its very nature, a parser is a partial function—some values in the domain do not correspond to any value in the range—so all parsers must have some notion of failure.

---

We're working on improving the documentation in general, but I plan to write a more TypeScript friendly guide about this subject rather than always pointing people at Lexi's (very extremely excellent) article. In the meantime, I definitely encourage reading and re-reading the article a few times (I do so every month or so 😆) until it starts to make more sense. I'll leave this issue open for visibility while we're working on the docs and welcome any follow-up questions!

[MartinMuzatko]

Thank you a lot for your kind words :) I keep reading many of the topics related to the functional programming realm, and it definitely resonates with me.
Thank you for clearing up things! Our IoT software is now slowly adapting zod, and if I get the chance to contribute, I will 👍