fix(typebox): improve type interface

[kotarella1110]

resolve #753 (comment)

Unlike other resolvers like zod, which can take Input, Context, and Output as generic arguments, it is not feasible to achieve a similar interface with typebox.

suggested type:

export function typeboxResolver<Schema extends TObject, Context>(
  schema: Schema | TypeCheck<Schema>,
): Resolver<Static<Schema>, Context, StaticDecode<Schema>>;

rationale:

• In typebox, the TObject type accepts TProperties as an argument, which differs from the Input (FieldValues) concept in other resolvers.
• As demonstrated below, attempting to generate a schema type from an Input (FieldValues) would result in a type error:

// TypeError: The type '{ id: number; }' does not satisfy the constraint 'TProperties'. Property 'id' is incompatible with the index signature. Type 'number' is not assignable to type 'TSchema'.
const schema: TObject<{ id: number }> = Type.Object({
  id: Type.Transform(Type.Number())
    .Decode((v) => String(v))
    .Encode((v) => Number.parseInt(v)),
});

// Correct implementation:
const schema: TObject<{ id: TTransform<TNumber, string> }> = Type.Object({
  id: Type.Transform(Type.Number())
    .Decode((v) => String(v))
    .Encode((v) => Number.parseInt(v)),
});

If we attempted to replicate the interface seen in zod, it would require defining the schema type explicitly as a generic parameter, which is not practical or realistic for users:

export function typeboxResolver<
  Schema extends TObject,
  Input extends Static<Schema> = FieldValues,
  Context,
  Output extends StaticDecode<Schema>
>(
  schema: Schema | TypeCheck<Schema>,
): Resolver<Input, Context, Output>;

Given these constraints, the initially proposed typing is the most feasible approach for typebox. It prioritizes usability while maintaining type safety.

[jorisre]

Thanks for the help and the explanation :)