feat: add parser middleware

[aztalbot]

Feature: Parser Middleware

• adds a new package for a parser middleware
• heavily based on the existing validator middleware
• also performs validation, just like the validator middleware
• relies on Zod ("TypeScript-first schema validation with static type inference")
• provides type inference from the schema into the handler

Example:

const middleware = parser({
  eventSchema: z.object({ body: z.string() }),
  contextSchema: z.object({ config: z.object({ batchSize: z.number().int() }) }),
  responseSchema: z.object({ results: z.array(z.string()).min(1).max(100) })
})

// handler event and context has type correct inference
const handler = middy().use(middleware).handler(async (event, context) => {
  expectType<{ body: string }>(event)
  expectType<Context & { config: { batchSize: number } }>(context)
  return { results: [''] }
})

Why another package?

This parser package and the validator package are very similar. But, teams already using Zod for other parsing or who don't want to use JSON-schema for validation, might want an alternative. AWS Powertools, for example, is considering separate RFCs for a validator and a parser (aws-powertools/powertools-lambda-typescript#1334). The main thing, though, is providing a more lightweight and intuitive way to do parsing and validation, while getting good type inference. Also, JSON-schema is a completely valid way to solve the problem, hence this parser package is just another option depending on user preference.

Error handling

The error handling in this package differs slightly from the existing validator package. The reason for this is I have run into the need in projects to customize the error: from the status code to the message. The createErrorFunc option gives full control over the error creation, so users can make the middleware easily fit their requirements. This also means the package doesn't need to have any responsibility for i18n, since the user can handle that in the error creation.

Performance

Based on the benchmark tests, the validator package does seem to be much more performant. Zod has made improvements in performance, but there is still room to improve there. See colinhacks/zod#205

Note:
totally understand if you choose not to accept this package into Middy and prefer to keep as a community package

[socket-security]

New dependencies detected. Learn more about Socket for GitHub ↗︎

Packages	Version	New capabilities	Transitives	Size	Publisher
@middy/util	4.6.2	None	+0	36 kB	lmammino
@types/aws-lambda	8.10.115	None	+0	136 kB	types
@types/node	20.2.5	None	+0	3.78 MB	types
zod	3.22.2	None	+0	616 kB	colinmcd94
@aws-sdk/client-ssm	3.342.0	network, filesystem, shell, environment	+60	6.97 MB	aws-sdk-bot

[willfarrell]

Thanks for putting this together, a zod validator is most welcome. I'd prefer it as a community validator at this time. Just let me know the link or open a. PR to include in the docs (website.docs/middlewares/third-party.md). One thing I can also do is link to community validators from the middleware page so people know they have options.