essential/validation

[giscus[bot]]

essential/validation

Schemas are strictly typed definitions, used to infer TypeScript's type and data validation of an incoming request and outgoing response. Elysia's schema validation is based on Sinclair's TypeBox, a TypeScript library for data validation.

https://elysiajs.com/essential/validation

[uchman005]

Can I use Zod for validation, since that's what the project is using Clent side already, or must I use t from Elysia?

[fecony]

Can I use Zod for validation, since that's what the project is using Clent side already, or must I use t from Elysia?

Refer to this link https://tsplay.dev/mqnxrW by @sinclairzx81

[uchman005]

Thanks for the prompt reply, however. The code sample by @sinclairzx81 You refered me to

...redacted excessive code...

TypeError: Right hand side of instanceof is not an object
at FromType (C:\Users\USER\Desktop\typebox\node_modules@sinclair\typemap\build\esm\typebox\typebox-from-zod.mjs:175:49)
at C:\Users\USER\Desktop\typebox\src\index.ts:13:13
at loadAndEvaluateModule (2:1)

Bun v1.2.20 (Windows x64)
What else can I do?

[fecony]

What else can I do?

It doesn't support zod@4 yet, use v3 for that

Other than that Elysia is built on Typebox and is not supporting other validators now

[uchman005]

Thanks, this was really helpful

[ghost]

How can I have a response validator for 200 but keep the default for the other error codes?

{
      headers: headersValidator,
      query: searchValidator,
      response: {
        200: getAllResponseValidator,
      },
      beforeHandle({ headers, status }) {
        const apiKey = headers['x-api-key'];
        if (!apiKey) {
          return status(401);
        }

        const payload = jwtSigner.decode(apiKey);
        if (payload.role !== 'admin') {
          return status(403);
        }
      },
    }

For example, this wont work because, 401 and 403 just blow up errors.

[ghost]

Hey! Just found it out here: elysiajs/elysia#1164

Basically we can have a default field with this value: t.Ref('message') and everything works :)

[blackfyre]

Well, here's an interesting issue 😅

Soo, since we're building an API and a lot of responses are standardized, we decided to create a cannedResponses object to make our lives easier, but it seems that typehinting has some issues with it...

While cannedResponses look like this:

import { t } from "elysia";
export const cannedResponses = {
	400: t.Object(
		{
			message: t.String({
				description: "Error message for bad requests",
				example: "Bad request",
				default: "Bad request",
			}),
		},
		{
			description: "Bad request error",
		},
	),
	401: t.Object(
		{
			message: t.String({
				description: "Error message for unauthorized access",
				example: "Unauthorized",
				default: "Unauthorized",
			}),
		},
		{
			description: "Unauthorized access",
		},
	),
	403: t.Object(
		{
			message: t.String({
				description: "Error message for forbidden access",
				example: "Forbidden",
				default: "Forbidden",
			}),
		},
		{
			description: "Forbidden access",
		},
	),
	...
};

For some reason the keys in `cannedResponses` are cast to string...

[Arthur944]

Is there a way to fully customize the validation errors that are returned to the client in a typesafe way?

I see how one can define custom error messages, but according to eden treaty a validation error always created a 422 status response with these fields:

{
type: "validation";
on: string;
summary?: string;
message?: string;
found?: unknown;
property?: string;
expected?: string;
}

what if i wanted to change the status code to something else? Or if I wanted to add an extra property on here? How could I do it in such a way that the eden treaty also knows about it?

[priosshrsth]

You should be able to that with .onError().

new Elysia()
.onError(({ error, status }) => {
  status(500).json({message: error.message})
}