Elysia is overriding the summary property with my custom validation message

[jasperdunn]

What version of Elysia is running?

1.2.0

What platform is your computer?

macOS

What steps can reproduce the bug?

// typebox-error-messages.ts

import {
  DefaultErrorFunction,
  SetErrorFunction,
  ValueErrorType,
} from '@sinclair/typebox/errors';

SetErrorFunction((error) => {
  if (error.errorType === ValueErrorType.StringFormat) {
    if (error.schema['format'] === 'email') {
      return 'Please enter a valid email address.';
    }
  }

  return DefaultErrorFunction(error);
});

// Response data from the endpoint after an invalid request payload
{
  . . . .
  "summary": "Property 'email' should be Please enter a valid email address",
  "property": "/email",
  "message": "Please enter a valid email address.",
  . . . .
}

What is the expected behavior?

// Response data from the endpoint after an invalid request payload
{
  . . . .
  "summary": "Property 'email' should be email",
  "property": "/email",
  "message": "Please enter a valid email address.",
  . . . .
}

I don't think summary makes sense here really anyway since it's contextually incorrect, but this is the default behaviour for an email. Is this an Elysia property and not part of TypeBox?

Regardless, why is elysia adding it's own validation error data anyway? Wouldn't it be best to keep things simple and utilize TypeBox to it's full potential and/or let users customize the error themselves?

The code in the link within "Additional information" below feels completely redundant to me.

Additional information

Here is the code overriding the Sinclair TypeBox custom error message behaviour:

elysia/src/error.ts

Line 142 in 1ca0ef1

: `Property '${property}' should be ${format}`

[jasperdunn]

elysia/src/error.ts

Lines 130 to 143 in 1ca0ef1

	case 50:
	// Expected string to match 'email' format
	const quoteIndex = message.indexOf("'")!
	const format = message.slice(
	quoteIndex + 1,
	message.indexOf("'", quoteIndex + 1)
	)
	return {
	...error,
	summary: isRoot
	? `Value should be an email`
	: `Property '${property}' should be ${format}`
	}

This code in particular, why are we assuming that a formatted string is an email if the path is ""?

I vote to scrap that entire function tbh.