You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We're comparing different schema validation libraries and one of my strongest concerns is the possibility to lie with class-validator. Here is an obviously stupid example, but it shows how we can have validators that make zero sense with the type, but will still wait for runtime to fail:
classTestClass{
@IsOptional()
@IsString()age: number
@IsBoolean()lastName?: string
@IsBoolean()firstName?: string}consttstObj1=newTestClass()tstObj1.age=42tstObj1.firstName=undefinedtstObj1.lastName='test'expect(validateSync(tstObj1)).toEqual([{target: tstObj1,value: 42,property: 'age',children: [],constraints: {isString: 'age must be a string'},},{target: tstObj1,value: 'test',property: 'lastName',children: [],constraints: {isBoolean: 'lastName must be a boolean value'},},{target: tstObj1,value: undefined,property: 'firstName',children: [],constraints: {isBoolean: 'firstName must be a boolean value'},},])
In "real life" this happened with @IsOptional() which had been added where it should have not, and was not here where it should have. But I guess in bigger models it can happen on more sever cases.
How can I ensure the validators and the types always match, at least for the basics?
What I expected here
Typing errors preventing compilation:
Cannot use @IsOptional() @IsString() on "age" as string | null | undefined is not compatible with number
Cannot use @IsBoolean() on "lastName" as boolean is not compatible with string | undefined
Cannot use @IsBoolean() on "firstName" as boolean is not compatible with string | undefined
Maybe it's just a limitation of the decorators, I still hope it can be achieved with strictier typing on validators.
The text was updated successfully, but these errors were encountered:
I decided to create my own wrapper decorators and wait for lib to switch away from legacy decorators first.
Suspect that a lot of type safety will be solved when class-validator will switch away from legacy decorators.
We're comparing different schema validation libraries and one of my strongest concerns is the possibility to lie with
class-validator
. Here is an obviously stupid example, but it shows how we can have validators that make zero sense with the type, but will still wait for runtime to fail:In "real life" this happened with
@IsOptional()
which had been added where it should have not, and was not here where it should have. But I guess in bigger models it can happen on more sever cases.How can I ensure the validators and the types always match, at least for the basics?
What I expected here
Typing errors preventing compilation:
@IsOptional() @IsString()
on "age" asstring | null | undefined
is not compatible withnumber
@IsBoolean()
on "lastName" asboolean
is not compatible withstring | undefined
@IsBoolean()
on "firstName" asboolean
is not compatible withstring | undefined
Maybe it's just a limitation of the decorators, I still hope it can be achieved with strictier typing on validators.
The text was updated successfully, but these errors were encountered: