Changes proposed in this pull request
We currently use class-validator in conjunction with NestJS to validate request objects. However, that doesn't really cover us. There are lots of places in the code where, for example, we accept any as a request object and then cast it to something else later, or we break the request object up into several simple types and then pass those on to other functions.
Now we can validate parameters that are passed to any function at runtime!
This is obviously a very limited set of validations that I've included up front. They are:
@LessThan(n: number) -- This will allow you to state that the parameter is less than some number n
@GreaterThan(n: number) -- This will allow you to state that the parameter is greater than some number n
@IsInteger -- This will allow you to state that some parameter is actually an integer and not a string, object, float, or whatever
One open question is whether this should be @IsInteger or @IsInt? In the latter case, it matches/conflicts with class-validator's identically named property decorator. They could very easily be used in the same class, so I'm not sure what the right move is here.
@IsValidInstance -- This is the most "interesting" one in that it allows you to validate a parameter whose type uses class-validator property validations.
At a high level, to use one of these validations, decorate the appropriate parameter with the validation you care about, then decorate the function with the @ValidateParams decorator. I'd recommend looking into the test suites that I added to get a sense of how to use these. Each individual decorator has some documentation that should prove to be helpful too.
The existing functionality provided by NestJS + class-validator via the ProtocolValidationPipe remains in tact. Its underlying error formatting is re-used by this new parameter validation code.
š Deployment changes š
(list added or removed env, db changes etc)
Signed-off-by: Jeff Kennedy jeffk@kiva.org
(Click here if you don't understand these emojis)
What issue is this targeting?
Changes proposed in this pull request We currently use class-validator in conjunction with NestJS to validate request objects. However, that doesn't really cover us. There are lots of places in the code where, for example, we accept
anyas a request object and then cast it to something else later, or we break the request object up into several simple types and then pass those on to other functions.Now we can validate parameters that are passed to any function at runtime!
This is obviously a very limited set of validations that I've included up front. They are:
@LessThan(n: number)-- This will allow you to state that the parameter is less than some number n@GreaterThan(n: number)-- This will allow you to state that the parameter is greater than some number n@IsInteger-- This will allow you to state that some parameter is actually an integer and not a string, object, float, or whatever@IsIntegeror@IsInt? In the latter case, it matches/conflicts with class-validator's identically named property decorator. They could very easily be used in the same class, so I'm not sure what the right move is here.@IsValidInstance-- This is the most "interesting" one in that it allows you to validate a parameter whose type usesclass-validatorproperty validations.At a high level, to use one of these validations, decorate the appropriate parameter with the validation you care about, then decorate the function with the
@ValidateParamsdecorator. I'd recommend looking into the test suites that I added to get a sense of how to use these. Each individual decorator has some documentation that should prove to be helpful too.The existing functionality provided by NestJS + class-validator via the ProtocolValidationPipe remains in tact. Its underlying error formatting is re-used by this new parameter validation code.
š Deployment changes š
(list added or removed env, db changes etc)
Other Notes