Feature Request: Support Zod 4.x

[alexbaileyxplor]

Summary

Zod 4 is stable and available to use today (https://zod.dev/v4). It comes with a range of improvements which I won't reiterate here.

Why is this needed?

• Significant performance improvements have been benchmarked should reduce costs for people running with the Parser component.
• 2x reduction in core bundle size should lead to reduced Lambda function packages.
• Multiple new features and a significantly improved API.

Which area does this relate to?

Parser

Solution

Update to Zod 4 for Parser. On the surface, it looks like many API's are backwards compatible. See https://zod.dev/v4/changelog for full migration guide. Most changes also seem to be deprecated rather than backwards breaking.

Acknowledgment

• This request meets Powertools for AWS Lambda (TypeScript) Tenets
• Should this be considered in other Powertools for AWS Lambda languages? i.e. Python, Java, and .NET

Future readers

Please react with 👍 and your use case to help us understand customer demand.

[boring-cyborg]

Thanks for opening your first issue here! We'll come back to you as soon as we can.
In the meantime, check out the #typescript channel on our Powertools for AWS Lambda Discord: Invite link

[dreamorosi]

We've been looking into supporting the new major version and from our side, especially when it comes to built-in schemas we ship, the changes are doable relatively easily.

The main question I'd like to hear from customers/users of our Parser library is whether they'd be ok with us forcing them into upgrading Zod.

Even by ignoring the fact that if we were to be strict about semantic versioning this upgrade would require us to release a major version, Zod's own author seems to have acknowledged that migrating from v3 to v4 might require some time, especially for end customers.

In short, if customers are already using v3 with/without Parser, us upgrading to v4 would break them and force them to upgrade as well, or have two copies of Zod in their bundle, which is not advisable.

From our side we'll make all the steps necessary to migrate, like upgrading our TypeScript configs to be able to leverage the sub-path exports and also upgrade the documentation to specify that for now we support only v3.

I'd like to leave this issue open for a while and hear from customers who are already using Parser, would you prefer us to upgrade to v4 right away or stay on v3 for a while longer?

[alexbaileyxplor]

@dreamorosi thanks for the update. Personally I'd be totally fine with forcing an update. However, not all customers will be in that position. As an alternative, is it possible to take a similar approach to Zod where we have a separate path to import from for v4? That way we can do the work to upgrade this package now, and then remove the v3 version in a future, breaking change.

[dreamorosi]

As an alternative, is it possible to take a similar approach to Zod where we have a separate path to import from for v4

It's possible, but I don't know if we'll want to go in this direction.

Supporting both would mean duplicating practically the entire codebase under packages/parser/src and packages/parser/tests, as well as potentially a good chunk of the documentation to account for differences.

Zod had good reasons to do this because they have a lot of libraries that depend on them, and for many users Zod is only a transitive dependency. Parser on the other hand is an end-user library, so customers using it can decide whether they want to stay on a version of Parser that supports Zod v3 or upgrade to one that supports v4.

With Zod being the only dependency of Parser is also unlikely that there will be many reasons to want to upgrade Parser beyond new/updated built-in schemas, so in practice we could theoretically upgrade to v4 and let customers who want to stay on v3 continue using that version of Parser.

With that said I'd rather hear from more people and see if we have concerns with migrating to v4 before committing time/resources in creating doubles of all our schemas/envelopes.