Is your feature request related to a problem?
When using type-graphql with class-level validation, I need to override or disable validation on a per-field basis. Currently, FieldOptions only extends AdvancedOptions (which covers deprecation, naming, complexity, and description), but it does not include ValidateOptions. This means validate and validateFn cannot be configured at the field level, only at the class/resolver level via @ObjectType or @Resolver.
Solution that I like
Extend FieldOptions to also include ValidateOptions:
// Current
export type FieldOptions = AdvancedOptions & {
simple?: boolean;
};
// Proposed
export type FieldOptions = AdvancedOptions & ValidateOptions & {
simple?: boolean;
};
This would allow per-field validation control, for example:
@ObjectType()
class Comment {
@Field(() => String, { validate: false })
rawHtml: string;
@Field(() => String, { validateFn: customValidator })
body: string;
}
Alternatives that I considered
- Class-level
validate: false + manual field validation, works but defeats the purpose of declarative validation and requires imperative boilerplate inside resolvers.
- Custom middleware on the field, possible but verbose; requires a separate
@UseMiddleware decorator per field, which pollutes the type definition and splits validation config across multiple decorators.
- Wrapping the type in a new
@ObjectType, over-engineered for what is essentially a per-field config concern.
Additional context
ValidateOptions is already defined in decorators/types.d.ts and used in @Arg and @Args decorators, so the plumbing already exists. Adding it to FieldOptions is a consistent extension of an existing pattern within the library.
Related types for reference:
FieldOptions, currently AdvancedOptions & { simple?: boolean }
ValidateOptions,{ validate?: ValidateSettings; validateFn?: ValidatorFn }
Is your feature request related to a problem?
When using
type-graphqlwith class-level validation, I need to override or disable validation on a per-field basis. Currently,FieldOptionsonly extendsAdvancedOptions(which covers deprecation, naming, complexity, and description), but it does not includeValidateOptions. This meansvalidateandvalidateFncannot be configured at the field level, only at the class/resolver level via@ObjectTypeor@Resolver.Solution that I like
Extend
FieldOptionsto also includeValidateOptions:This would allow per-field validation control, for example:
Alternatives that I considered
validate: false+ manual field validation, works but defeats the purpose of declarative validation and requires imperative boilerplate inside resolvers.@UseMiddlewaredecorator per field, which pollutes the type definition and splits validation config across multiple decorators.@ObjectType, over-engineered for what is essentially a per-field config concern.Additional context
ValidateOptionsis already defined indecorators/types.d.tsand used in@Argand@Argsdecorators, so the plumbing already exists. Adding it toFieldOptionsis a consistent extension of an existing pattern within the library.Related types for reference:
FieldOptions, currentlyAdvancedOptions & { simple?: boolean }ValidateOptions,{ validate?: ValidateSettings; validateFn?: ValidatorFn }