Valibot is really nice, particularly for avoiding bundle size bloat. Because Zod uses a "fluent builder" API, all of Zod's functionality is implemented in classes with many methods. Importing something like `z.string` also imports validators to check if the string is a UUID, email address, has a minimum or maximum length, matches a regex, and so on - even if none of those validators are used. Valibot makes these independent functions that are composed using the "pipe" function, which means that only the functions which are actually used need to be included in your JavaScript bundle. Since most apps use only a small percentage of the available validators, the bundle size reduction can be quite significant relative to Zod.

Is there a reason why tree shaking algorithms don't prune unused class members? My IDE can tell me when a method is unused, it seems odd that the tree shaker can't.

Does that work for all class members? I think I've only ever seen that on private members, though I don't know whether that's because it's so much easier to check whether a private member is used or because an unused public member isn't an issue for eg a library.

This feels like an issue that reduces down to the Halting Problem, though. Halting is a function that could be made a member of a class, so if you could tell whether that method is used or not then you could tell whether the program will halt or not. I think it's one of those things that feels like it should be fairly easy, and it's really really not.

Comparing this to the halting problem isn't really meaningful here because even if you could make a full mapping (which yours isn't), you can prove that a rather large subset of programs halt, which is good enough for a tree shaker.

I don't need to be able to eliminate every single unused function in every situation, but if I can prove that certain functions are unused then I can delete just those functions. We're already doing this regularly with standalone functions, so my question is just why this isn't done with class members.

Ah, I see your question now. Prototypes maybe? I’m not nearly a good enough JS dev to have a reasonable guess at that specifically.

Being able to access class members using square bracket syntax with a variable also seems like it would make it really difficult to prove that something isn’t used. I’m thinking something unhinged like using parameters to build a string named after a class member and then accessing it that way.

Dunno, I would be curious if someone has a definitive answer as well.

It requires flow analysis, which is really hard to get right. I don't think there's a tree-shaking library that uses the TypeScript compiler API for static analysis purposes. Maybe because it would be slow?

edit: The creator of Terser is working on flow analysis for his new minifier, according to him[1].

[1]: https://github.com/terser/terser/issues/1410#issuecomment-17...

* Not the creator of Terser, but the lead maintainer

Because you can write `this[anything()]()` and it's impossible to analyze it. IDE false negative will not do anything bad, but treeshaker false negative will introduce a bug, so they have to be conservative.

That's not entirely true. Tree-shaking algorithms could have a “noDynamicAccess” option that errors on such use (only viable for applications, not libraries). Alternatively, the algorithm could be integrated with the TypeScript compiler API to allow dynamic access in some cases (e.g. where the `anything` function in your example only returns a “string literal” constant type or a union thereof, instead of the `string` type).

Valibot also has much, much more efficient type inference, which sounds unimportant right up until you have 50 schemas referencing each other and all your Typescript stuff slows to a molasses crawl.

Agreed. I recently moved a production app from Zod to Valibot for exactly this reason. I still slightly prefer Zod’s syntax but the performance issues were absolutely killing us.

Not only that, runtime schema validation was also way faster in my last project for larger arrays of complex objects with lots of union types. Went from 400ms to 24ms all else being equal. Since our validation was running on every request for certain reasons this made a huge difference in perceived performance for our users and less load on our servers.

Does/will this correctly handle `| undefined` vs `?`, i.e. correct behavior under `exactOptionalPropertyTypes`?

Zod doesn't (yet[0]) and it's been a pain point for me.

[0] https://github.com/colinhacks/zod/issues/635

I ran into exactly same pain point which was enough to nullify the benefits of using zod at all.

TypeBox[1] differentiates between optional and undefined.

[1]: https://github.com/sinclairzx81/typebox

It does: https://valibot.dev/guides/optionals/#use-in-objects

  import * as v from 'valibot';
  const OptionalKeySchema = v.object({ key: v.optional(v.string()) });
  type t1 = v.InferInput<typeof OptionalKeySchema>; // { key?: string }

  const UndefinedKeySchema = v.object({ key: v.undefinedable(v.string()) });
  type t2 = v.InferInput<typeof UndefinedKeySchema>; // { key: undefined }

Is Valibot's error handling any good? Zod's is… like punishment for a crime I wasn't aware that I had committed.

I'm currently using valibot and the author's associated modular form library in a production app and can vouch that it's been very pleasant to work with.

I recently stumbled onto this when looking for alternatives, and though it might sound a bit extreme: the style of documentation means I'll never consider it for any project. It's strange and honestly somehow unnerving to read documentation written from a first-person perspective. Is there some good reason for this that I'm missing? Or am I just crazy and this isn't an issue for anyone else?

I only see second-person "you" and not first-person "I" in the linked documentation. Am I missing what you intended to point out?

In any case, this might actually be a good use for an LLM to post-process it into whatever style you want. I bet there's even a browser extension that could do it on-demand and in-place.

Really? For example under "Main concepts" on the "Schemas" site[0], I see stuff like this:

- I support the creation of schemas for any primitive data type.

- Among complex values I support objects, records, arrays, tuples as well as various other classes.

- For objects I provide various methods like pick, omit, partial and required.

- Beyond primitive and complex values, I also provide schema functions for more special cases.

Same for "Mental model", "Pipeline", "Parse data", "Infer types", "Methods" and "Issues" - I'll assume the other sections also follow this style. That's all not showing up for you?

While the LLM suggestion is nice, it's not something I'm comfortable with unless hallucinations are incredibly rare. Why would I use a library whose documentation I have to pass through an unreliable preprocessor to follow a normal style?

[0]: https://valibot.dev/guides/schemas/

If they're part of Hacktoberfest, editing those pages to drop the first person perspective sounds like a pretty useful first contribution.

It seems I'm not the first person to make this observation: https://github.com/fabian-hiller/valibot/issues/687

I honestly don't want my validation library to "tell a story" at the expense of documentation clarity. It's absolutely fine that this project uses it, I don't want to impose my view on them - I guess it's just not the validation library for me.

> Or am I just crazy and this isn't an issue for anyone else?

Not an issue for me, to be honest. Why does it bother you at all?

I'm not exactly sure myself, but every time I open one of the pages, I mentally stumble over the formulations. I think there are two components:

1. The biggest part is that I've simply never seen documentation written in this style, any mentions of "I" or "we" are usually explaining the choices made by the author(s). When skimming documentation I pay more attention to those parts. Here those parts don't have a comparable meaning.

2. The smaller part is that the writing style reminds me of the way brands use mascots with first-person writing to advertise to children. There's not really any other association I have with this way of writing, and it makes me feel like the author either isn't taking the project seriously, or me.

I'm not trying to argue that the documentation should be understood this way, or that it should be changed - but I've stumbled over this multiple times, and can't imagine that it's just me.

It's a little too cute, but I don't see it as a deciding factor on which library to use.

I think a more important issue is that Valibot hasn't reached 1.0 yet. But it looks like it's very close.

Yes, that's just cringe.

I don't think you are crazy at all. The concept of professionalism is about doing things a certain way to indicate to others that you are, of course, a professional. Writing technical documents in the 3rd person is a basic part of what I would consider professionalism in the broader engineering field.

In the software field you get a large portion of people that don't buy into the concept of professionalism. For various reasons - chiefly the hacker culture and the easy of contributing to the "field" means the gauntlet one runs to become a "professional" isn't inherently a given.

As a whole this is a good thing but it does mean if you operate as a "professional" maybe sometimes you have to realize that something doesn't exactly gel with your ethos (case in point). It doesn't mean it is bad; just maybe not for you and yours.

Thank you for sharing your perspective, I hadn't really thought about that angle. If a colleague asked me to explain my choice, I feel there'd be some appearance of being convinced by style over substance.

There's still more at play, since I really keep visually stumbling over those sentences, but that seems to be more related to me. And you're absolutely right that this doesn't make the project objectively worse - I wish them best of luck and hope their approach to documentation helps others!

A whole lot of yapping and ZERO code on the homepage. Authors should remove 90% of the stuff on that landing page, jesus!

also since zod is the de facto validation lib, might be worth a specific page talking about why this vs zod. even their migration from zod page looks nearly identical between the two packages.

On the front page there is a prominent section addressing the differences from Zod, which appear to be “much better performance”

Maybe OP is one of the lucky 10,000. https://xkcd.com/1053/