5 ms·

Congratulations to the Zod team on the new release. At the risk of sounding overtly negative, I can't help but shudder when I think about the number of breaking

by 8s2ngy 1y ago

Congratulations to the Zod team on the new release. At the risk of sounding overtly negative, I can't help but shudder when I think about the number of breaking changes outlined in the migration guide. For projects that rely heavily on Zod, it feels like a daunting task ahead—one that will demand a lot of developer attention and time to navigate. Having maintained a few frontend projects that are 4-5 years old at work, I really empathize with them. In my experience, large React projects often depend on a multitude of libraries, and when each one rolls out substantial changes—sometimes with barely any documentation—it can quickly become overwhelming. This is honestly one of my least favorite aspects of working with JavaScript. It just feels like a constant uphill battle to keep everything in sync and functioning smoothly.

koakuma-chan 1y ago
> For projects that rely heavily on Zod, it feels like a daunting task ahead—one that will demand a lot of developer attention and time to navigate. Or just use an LLM.
- camgunz 1y ago
  And then pick through all the LLM's mistakes.
  - rvnx 1y ago
    Ask another LLM to pick for you
- owebmaster 1y ago
  better yet: use an LLM to generate a subset of Zod that is fit for the project
- cscheid 1y ago
  This is the kind of task that LLMs are precisely terrible at; there isn't an abundance of Zod 4 examples, and the LLM will sure as shit will give you _something_ you are now by definition ill-equipped to assess. I'm confident about this assessment because I maintain a large-ish piece of software and perenially have to decipher user reports of hallucinated LLM syntax for new features.
  - koakuma-chan 1y ago
    Are you sure that's not a skill issue? Zod v4 has .mdx documentation which can be given to the LLM as context, including a migration guide. A reasoning LLM should be able to manage.
    - collingreen 1y ago
      "It will solve all your problems!" "It didn't solve my problems" "You're the problem!"
      - koakuma-chan 1y ago
        > "You're the problem!" He said users sent reports with hallucinated syntax, he wasn't even the one who used LLMs.
    - elanora96 1y ago
      I've only tried Claude in Cursor's free trial, but it became very confused during a React 19 upgrade even after showing it a guide. It also kept telling me to install irrelevant dependencies saying my code would not work without them. My experience was more or less shared with several other senior devs using their companies AI subscriptions. Are we all using the tools wrong? Or is there just an expected amount of having to fight with the machine to get a usable result?
      - koakuma-chan 1y ago
        > I've only tried Claude in Cursor's free trial, but it became very confused during a React 19 upgrade even after showing it a guide. I have never used Cursor, but I see more and more people who used LLMs specifically via Cursor complain. It makes me think there's an issue specifically with Cursor, e.g., they try to save on tokens and end up not including enough context in the prompt. > I've only tried Claude in Cursor's free trial, but it became very confused during a React 19 upgrade even after showing it a guide. I am working on a Next.js 15 / React 19 app, and at least 95% of code is written by Gemini 2.5 Pro Preview, and I barely ever need to "fight" it really. But it's not a Cursor workflow of course. I keep a directory with LLM-readable documentation[0], use a repository serialization tool to serialize my repository into a prompt (this includes both the source code and the LLM-readable documentation), and send it to Gemini 2.5 Pro Preview. It ends up being over 100K tokens per query but works really well for me. [0]: https://llmstxt.org/ https://llmstxt.org/
- sensanaty 1y ago
  LLMs can't even not write React when you explicitly tell them not to write React in your Vue codebase. I still, with Gemini 2.5 Pro and Claude 3.7 both, get this annoying ass interaction almost daily, despite a universe of context there that should make it obvious I don't want a React component in my Vue codebase.
  - 9dev 1y ago
    Do you mean TSX? Because Vue supports that. Might be worth asking it to create a SFC file and no TSX explicitly in your case!
ruined 1y ago
that's why they're taking the dual-availability approach, with a separate 'mini' edition. it's easy to perform a progressive migration without messing with the package manager. consumers uninterested in the 'mini' edition don't have to bother with that part. but, the benefits of the 'mini' edition are so drastic for tree-shaking that it was driving development of alternatives - zod had to either do it (and benefit), or deprecate.
- JoRyGu 1y ago
  Was just looking at their release strategy. This is being handled by people that have experienced the hell that is dependency management in the JS ecosystem. Kudos to them.
nicksergeant 1y ago
I am 100% in agreement here. I operate a couple large Next.js apps and in the last year we've had to deal with Next.js 14 -> 15 which introduced a ton of breaking cache changes, Next.js pages -> app router, React 18 -> 19, Eslint 8 -> 9, and Tailwind 3 -> 4. It's honestly been a nightmare, and I wish I had just built in Django instead. The Tailwind 3 -> 4 migration was probably among the most painful, which I was not expecting.
- Daishiman 1y ago
  I will continue to beat the drum that using easy-to-migrate frameworks like Django that don't go around introducing major breaking changes is one of the bigger web development superpowers.
  - hombre_fatal 1y ago
    Django doesn't run in the browser though. All of the tech they listed can run in the browser which gives you other superpowers at the expense of having moving targets, but that's what they opted into when they decided to run code on user machines instead of in a single server environment.
    - skydhash 1y ago
      The main browser API is pretty stable, all things considered. It's just that people can't seem to stay put on a given design, instead trying everything under the sun. When you have something like SDL which is at it's third version at 27 years old, I'm very doubtful about the culture of NPM/JS world. A closer example is jQuery which is also in its third version at 18 years old.
      - hombre_fatal 1y ago
        True, the browser API might be stable, but the best way to build stateful client applications is unstable. It's a constantly improving and experimental domain - not just on the web but also the desktop and mobile environment. Next.js is a good example since it (and its competitors) are a natural iteration on top of SPAs where you want the first request to the server to also inline the initial state of the SPA to remove the double-request problem. But you pay a huge price trying to live on the edge like that, and when you run into issues, it doesn't make much sense to call that the state of web development since you could have used boring server tech or even a boring React SPA which also hasn't changed much in a decade.

by 8s2ngy 1y ago

koakuma-chan 1y ago

> For projects that rely heavily on Zod, it feels like a daunting task ahead—one that will demand a lot of developer attention and time to navigate. Or just use an LLM.

camgunz 1y ago
And then pick through all the LLM's mistakes.
- rvnx 1y ago
  Ask another LLM to pick for you
owebmaster 1y ago
better yet: use an LLM to generate a subset of Zod that is fit for the project
cscheid 1y ago
This is the kind of task that LLMs are precisely terrible at; there isn't an abundance of Zod 4 examples, and the LLM will sure as shit will give you _something_ you are now by definition ill-equipped to assess. I'm confident about this assessment because I maintain a large-ish piece of software and perenially have to decipher user reports of hallucinated LLM syntax for new features.
- koakuma-chan 1y ago
  Are you sure that's not a skill issue? Zod v4 has .mdx documentation which can be given to the LLM as context, including a migration guide. A reasoning LLM should be able to manage.
  - collingreen 1y ago
    "It will solve all your problems!" "It didn't solve my problems" "You're the problem!"
    - koakuma-chan 1y ago
      > "You're the problem!" He said users sent reports with hallucinated syntax, he wasn't even the one who used LLMs.
  - elanora96 1y ago
    I've only tried Claude in Cursor's free trial, but it became very confused during a React 19 upgrade even after showing it a guide. It also kept telling me to install irrelevant dependencies saying my code would not work without them. My experience was more or less shared with several other senior devs using their companies AI subscriptions. Are we all using the tools wrong? Or is there just an expected amount of having to fight with the machine to get a usable result?
    - koakuma-chan 1y ago
      > I've only tried Claude in Cursor's free trial, but it became very confused during a React 19 upgrade even after showing it a guide. I have never used Cursor, but I see more and more people who used LLMs specifically via Cursor complain. It makes me think there's an issue specifically with Cursor, e.g., they try to save on tokens and end up not including enough context in the prompt. > I've only tried Claude in Cursor's free trial, but it became very confused during a React 19 upgrade even after showing it a guide. I am working on a Next.js 15 / React 19 app, and at least 95% of code is written by Gemini 2.5 Pro Preview, and I barely ever need to "fight" it really. But it's not a Cursor workflow of course. I keep a directory with LLM-readable documentation[0], use a repository serialization tool to serialize my repository into a prompt (this includes both the source code and the LLM-readable documentation), and send it to Gemini 2.5 Pro Preview. It ends up being over 100K tokens per query but works really well for me. [0]: https://llmstxt.org/ https://llmstxt.org/
sensanaty 1y ago
LLMs can't even not write React when you explicitly tell them not to write React in your Vue codebase. I still, with Gemini 2.5 Pro and Claude 3.7 both, get this annoying ass interaction almost daily, despite a universe of context there that should make it obvious I don't want a React component in my Vue codebase.
- 9dev 1y ago
  Do you mean TSX? Because Vue supports that. Might be worth asking it to create a SFC file and no TSX explicitly in your case!

ruined 1y ago

that's why they're taking the dual-availability approach, with a separate 'mini' edition. it's easy to perform a progressive migration without messing with the package manager. consumers uninterested in the 'mini' edition don't have to bother with that part. but, the benefits of the 'mini' edition are so drastic for tree-shaking that it was driving development of alternatives - zod had to either do it (and benefit), or deprecate.

JoRyGu 1y ago
Was just looking at their release strategy. This is being handled by people that have experienced the hell that is dependency management in the JS ecosystem. Kudos to them.

nicksergeant 1y ago

I am 100% in agreement here. I operate a couple large Next.js apps and in the last year we've had to deal with Next.js 14 -> 15 which introduced a ton of breaking cache changes, Next.js pages -> app router, React 18 -> 19, Eslint 8 -> 9, and Tailwind 3 -> 4. It's honestly been a nightmare, and I wish I had just built in Django instead. The Tailwind 3 -> 4 migration was probably among the most painful, which I was not expecting.

Daishiman 1y ago
I will continue to beat the drum that using easy-to-migrate frameworks like Django that don't go around introducing major breaking changes is one of the bigger web development superpowers.
- hombre_fatal 1y ago
  Django doesn't run in the browser though. All of the tech they listed can run in the browser which gives you other superpowers at the expense of having moving targets, but that's what they opted into when they decided to run code on user machines instead of in a single server environment.
  - skydhash 1y ago
    The main browser API is pretty stable, all things considered. It's just that people can't seem to stay put on a given design, instead trying everything under the sun. When you have something like SDL which is at it's third version at 27 years old, I'm very doubtful about the culture of NPM/JS world. A closer example is jQuery which is also in its third version at 18 years old.
    - hombre_fatal 1y ago
      True, the browser API might be stable, but the best way to build stateful client applications is unstable. It's a constantly improving and experimental domain - not just on the web but also the desktop and mobile environment. Next.js is a good example since it (and its competitors) are a natural iteration on top of SPAs where you want the first request to the server to also inline the initial state of the SPA to remove the double-request problem. But you pay a huge price trying to live on the edge like that, and when you run into issues, it doesn't make much sense to call that the state of web development since you could have used boring server tech or even a boring React SPA which also hasn't changed much in a decade.