Add support for validating an empty class with forbidUnknownValues enabled

[machendos]

Let's imagine that we are developing an application architecture on which application programmers will then layer business logic. We are currently creating a validation layer that will automatically validate incoming inputs from clients, simply by obtaining an input metatype that will be described by our future application programmer. Of course for these, we use class-validator library

According to the recommendation from the documentation(https://github.com/typestack/class-validator#passing-options), we use the setting forbidUnknownValues: true directly in the call to the validate method

But if in many months, our application developer decides to describe the following class for input:

export class EmptyObjectDto {}

He will be very surprised, because the library will take a seemingly valid object for an invalid one, since there will not be a full registered decorator in it and it will give an error

Accordingly, he will not have any opportunity to give an empty input to our validation layer, and it will be necessary to add extra if->else from the area of responsibility to which he does not belong

Can we get around this somehow?

[NoNameProvided]

Yes, this use case should be supported.

The technical problem here is that without decorators assigned class-validator doesn't know about this class so when it receives an instance of it it will think it's an unknown value.

We need to discuss how should we add support for this. My first (so probably not the best) idea would be to add a class decorator something like @ValidatedClass:

@ValidatedClass()
export class EmptyObjectDto {}

This way class-validator will know about it and the validation will pass.

PS: I am moving this issue to discussions, so the community can brainstorm, iterate and propose an API that we can discuss.

[klansser]

Do we have any solution for this?

[henriqueleite42]

It would be amazing to add support for class-level decorators, I have a similar problem (described in #2393) that this can solve.

Some of the decorators that can exist are @IsNotEmptyObjectClass and @IsEmptyObjectClass, which would work exactly as the existent decorators @IsNotEmptyObject and @IsEmptyObject, but in the class directly instead of the method.

Or, the even best approach that I'm not sure if it's possible, is to use the same decorators, and adapt them to work also with classes.

[henriqueleite42]

I'm trying to implement class-level validation, but there's a lot of stuff to do before it can be done. I'll leave here a checklist to keep you guys updated, and tell me if I'm using the wrong branch (develop) or it these things are already fixed:

• Standardization (Optional)
  • Rename src/decorator/string/is-tax-id.ts to src/decorator/string/isTaxId.ts
  • Rename src/decorator/string/is-iso4217-currency-code.ts to src/decorator/string/isIso4217CurrencyCode.ts
• Organization (Optional)
  • Move src/decorator/string/IsPhoneNumber.spec.ts to test/decorator/string/IsPhoneNumber.spec.ts
  • Move src/decorator/common/IsIn.spec.ts to test/decorator/common/IsIn.spec.ts
• Required updates
  • Change the type of ValidationDecoratorOptions.property from propertyName: string to propertyName?: string | symbol, and change ALL the places that will be affected by this (a lot!)

I don't have much time now, but I'll be back to the required updates asp

[henriqueleite42]

I was trying to work on the required updates, but there are too many type errors to fix, in many parts of the lib.

Before making any changes to the lib functionalities, I prefer to fix them before to be sure that the changes I made will only have a positive impact.

I have open an PR #2401 to fix a bunch of type errors, and after the merge of the PR I'll work on the class-level validation.