The names of the decorators are lost in the MetadataStorage

[CyriacBr]

Description

Since the 0.12.x update, the names of the decorators are lost when stored.
For example, when the IsString decorator is used, the metadata store a new entry with the type customValidation instead of isString. This seems to apply to all decorators, because of this line:

class-validator/src/register-decorator.ts

Line 80 in 1955250

type: options.name && ValidationTypes.isValid(options.name) ? options.name : ValidationTypes.CUSTOM_VALIDATION,

.

Reproduction

Inspect the stored metadata with getMetadataStorage().getTargetValidationMetadatas and you'll see that all entries' types are customValidation, instead of their decorator names.

Environment

• nodejs: 10.18.1
• browser: no
• framework/library: standalone

class-validator version: 0.12.2

[nolazybits]

@vlapo @NoNameProvided would you have an idea on that one please?

[NoNameProvided]

Hi!

Can you please provide

• the commit where the change was introduced
• and your use-case (metadata storage is an internal part of the lib and it's not supposed to be consumed by anyone else than this lib)

[CyriacBr]

Hi. @NoNameProvided

The changes was introduced during the 0.12 update, removing all the decorator names from ValidatorType as you can see here.
Because of this change and this line:
type: options.name && ValidationTypes.isValid(options.name) ? options.name : ValidationTypes.CUSTOM_VALIDATION,
all decorators seem to be saved in the medata store with "customValidation" as the type, instead of their respective names "isString", "isNumber", etc.

The use case if that my lib can read class-validator decorators for a specific class, and generate fixtures based on them, instead of using redundant decorators. (a @IsString() decorator specifically says that the prop is a string).:

class Author {
  @IsString()
  @Fixture()      // redundant
  name: string;

  @IsNumber()
  @Fixture()      // redundant
  age: number;
}

But now the names are lost, making it impossible to know which decorators were used at all.

I'm not sure if the store isn't supposed to be consumed by anyone, as it's publicly exported. And I'd rather it be kept like that, there's no harm in providing third party libs with the metadata store, in my opinion.

Regardless of my use case, I think it's "wrong", to discard the names of the decorators when saved in the store.
One easy fix would be to add one more field to ValidationMetadataArgs:

const validationMetadataArgs: ValidationMetadataArgs = {
       name: options.name, // <=== we keep track of the decorator name
        type: options.name && ValidationTypes.isValid(options.name) ? options.name : ValidationTypes.CUSTOM_VALIDATION,
        target: options.target,
        propertyName: options.propertyName,
        validationOptions: options.options,
        constraintCls: constraintCls,
        constraints: options.constraints
    };
    getMetadataStorage().addValidationMetadata(new ValidationMetadata(validationMetadataArgs));

[ferbs]

Is there another way to extract the decorated property names? I was also using getTargetValidationMetadatas but it stopped working when I upgraded class-validator from 0.11.1 to 0.12.2. (My use case is plucking user-accessible fields for serialization.)

[NickKelly1]

Hi,

Ran into this fixing the inheritance issue #657. Given how ValidationType is used, it wasn't accurate to identify validators by it anyway.
I've submitted PR #748 which persists validators name

[nolazybits]

@NickKelly1 @CyriacBr I have open the PR from your fork to @ts-revival/class-validator here
ts-revival#9

following this comment
#812 (comment)

[Clashsoft]

My workaround: ValidationTypes.isValid = () => true; But this seems to break validation (everything is valid now)

[Clashsoft]

@NickKelly1 @CyriacBr I have open the PR from your fork to @ts-revival/class-validator here ts-revival#9

I'm glad this was ported over, but you never released it :/ @nolazybits