Maintenance: JSONStringified helper does not infer return type

[dreamorosi]

Summary

In 2.7.0 we introduced a new helper in the Parser utility, which helps customers to extend built-in Zod schemas that have a stringified body.

The helper, while working at runtime, currently sets the return type of the parsed object to any, which defeats the purpose of the DX improvement that the helper was supposed to bring.

We should

Why is this needed?

So that customers using the helper can have the correct type on the parsed field.

Which area does this relate to?

Parser

Solution

Follow Zod best practices around writing generic functions.

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.

[aripalo]

@dreamorosi "opened this issue 13 minutes ago" … I basically hit this problem like 15 minutes ago 😅

But yeah, this would definitely be an improvement to have JSONStringified return correct types for the handler.

I'm currently working on a personal project with this, but we also use PowerTools and the parser in our company.

We have multiple use cases with APIGatewayProxyEventSchema, APIGatewayProxyEventV2Schema and LambdaFunctionUrlSchema where we can't use an Envelope as we are very much interested about the request headers too; Therefore we're using the XEventSchemas and calling .extend on it, like this:

const MySchema = LambdaFunctionUrlSchema.extend({
  headers: MyCustomHeaderSchema,
  body: JSONStringified(MyCustomBodySchema),
});

And it'd be super useful to have the correct types in event.body. Of couse we can workaround it:

// inside the handler
const body = event.body as z.output<typeof MyCustomBodySchema>;

... but with a team(s) of multiple people developing things, that workaround is easy for someone to forget this workaround and spend time on debugging the incorrect type.

[aripalo]

… and of course another workaround is to use Middy's body JSON parser, then just assume the body is already JSON, and finally using MyCustomBodySchema directly on body… but that too is problematic because there's no "direct connection" between the Middy JSON body parser and the zod schema.

[dreamorosi]

Hi @aripalo, I already have a PR up that fixes this.

Should be merged on Monday and released mid next week 😊

[aripalo]

Fantastic! 😍

(… also the timing so I can use this as an excuse to put my coding project on hold until next week and actually enjoy the weekend 😄)

[github-actions]

⚠️ COMMENT VISIBILITY WARNING ⚠️

This issue is now closed. Please be mindful that future comments are hard for our team to see.

If you need more assistance, please either tag a team member or open a new issue that references this one.

If you wish to keep having a conversation with other community members under this issue feel free to do so.

[github-actions]

This is now released under v2.8.0 version!