9 ms·

I only use Zod in a single library, so my experience with it is pretty minimal. One thing I have really enjoyed with it is the low maintenance. So, when I saw

I only use Zod in a single library, so my experience with it is pretty minimal. One thing I have really enjoyed with it is the low maintenance. So, when I saw this post and read the first few paragraphs, I was filled with dread for having to do yet another major dependency update. Reading of all the improvements- surly the ‘breaking changes’ list must be massive. Having read the full article, it seems like the breaking changes have been kept within reason. One major improvement that stands out to me is the improved Recursive types support, but there is certainly any number of improvements for others to be excited about. The thing I enjoyed most is that excitement of the Arthur really shines throughout the whole article. I’m so thankful this library exists and is being lovingly maintained by someone who is genuinely interested in it.

ivanfeli 2y ago
I use it in a fairly big project. The only breaking change for me was z.record() now requiring two parameters, previously the second parameter was optional. The rest are deprecations that can be easily fixed like .email, etc.
simjnd 2y ago
Even if the breaking changes were massive, you could keep the dependency pinned at the version you're using and not upgrade if the new features aren't useful/compelling
- egorfine 1y ago
  That's not a feasible approach. You will have to upgrade at a certain point and the later - the more painful it would be.
egorfine 1y ago
> I was filled with dread for having to do yet another major dependency update. I am dreading. I have recently upgraded a few large breaking dependencies and at this point I'm dead inside. I'd rather remove zod and validation from the project than have another architectural shakedown of a minor piece of my project (validation). > breaking changes have been kept within reason There is always a reason why everything must be rewritten and broken[1]. [1] https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/ https://www.joelonsoftware.com/2001/04/21/dont-let-architect...

ivanfeli 2y ago

I use it in a fairly big project. The only breaking change for me was z.record() now requiring two parameters, previously the second parameter was optional. The rest are deprecations that can be easily fixed like .email, etc.

simjnd 2y ago

Even if the breaking changes were massive, you could keep the dependency pinned at the version you're using and not upgrade if the new features aren't useful/compelling

egorfine 1y ago
That's not a feasible approach. You will have to upgrade at a certain point and the later - the more painful it would be.

egorfine 1y ago

> I was filled with dread for having to do yet another major dependency update. I am dreading. I have recently upgraded a few large breaking dependencies and at this point I'm dead inside. I'd rather remove zod and validation from the project than have another architectural shakedown of a minor piece of my project (validation). > breaking changes have been kept within reason There is always a reason why everything must be rewritten and broken[1]. [1] https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/ https://www.joelonsoftware.com/2001/04/21/dont-let-architect...