ZBAGI

@NoNameProvided Personally i'm against complex logic in decorator definitions. Imagine having repeat those `val => typeof val == 'string'` in every property you want to validate. It quickly gets messy....

It should work exactly like [example shows](https://github.com/typestack/class-validator#validating-nested-objects). If you meant an array then [ValidationOptions.each](https://github.com/typestack/class-validator/blob/1955250de64d76504df465aa02076a2e5b219bb7/src/decorator/ValidationOptions.ts#L11) set to `true` should do the work. ```typescript class example { @IsType(["string", "int"], { each: true...

You can add whatever type checking function you wish Here is example that will look for `string` in property `typeName` ```ts const typeValidator = { "typeOne": function (value: any, args:...

I agree with you @jbjhjm Class inheritance is very important for me, it gives typescript more "typed" feeling. I don't understand why it was replaced with more JS-like approach instead...

From what i understand, `manager.withRepository()` simply propagates itself into instance. You can achieve the same effect by making `manager` that you want to use as an optional parameter. Ie: ```typescript...

For crying out loud @pleerock this issue has drawn a crowd, and it's like shouting into the void. How can it be brushed off like this? Some choices should be...