[alganet]

In validation, it's never about speed. Is how you relate the schema tree to the error reporting tree. If you didn't already, you will figure that out eventually.

If you mess that (either by being too flat, too customizeable or too limited), library users will start coming up with their own wrappers around it, which will make your stuff slower and your role as a maintainer hell.

(source: 15 years intermittently maintaining a similar project).

There is an obvious need for a validation library nowadays that bridges oop, functional and natural languages. Its value, if adopted as a standard, would be immense. The floor is still lava though, can't make it work in today's software culture.

[e1g]

Especially when unions are involved. We have a flexible schema for many parameters (e.g., X accepts an object or an array of them, and one object has some properties that could be an enum or a detailed shape), and both Zod and Valibot produce incomprehensible and useless error messages that don’t explain what’s wrong. We had to roll our own.

[alganet]

Have you tried applying boolean algebra conversions on the schema? Some ORs can be written as NOT AND expressions. I don't know about these JS versions, but in my lib the choice of boolean expression had influence on th3 error output.

[retropragma]

I find your last paragraph to be lacking. Would help if you elaborated more on the purported need for this "bridge" concept.

[alganet]

Maybe one day I will elaborate on it!

The need is obvious. As natural language becomes more proeminent in programming, there will be a need for a bridge to the older traditional paradigms. I can't give more details, it's the kind of thing you can't put in prose yet.