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 :)