search

darraghoriordan / eslint-plugin-nestjs-typed

Some eslint rules for working with NestJs projects
http://www.darraghoriordan.com
171 stars 34 forks source link

Properties with explicitly required values throws linting issues #185

Closed ChrisMBarr closed 3 months ago

ChrisMBarr commented 3 months ago

I have certain properties that require explicit values to always be sent, like this:

@IsNotEmpty()
@IsString()
@Equals('ZCATS') //we require the front end to always send us this exact literal string for some reason ¯\_(ツ)_/¯
Profile!: 'ZCATS';

@IsNotEmpty()
@IsBoolean()
@Equals(true) //we require the front end to always send us a literal true boolean for some reason ¯\_(ツ)_/¯
ReleaseData!: true;

But I am getting this linting error for both of these cases

A non-primitive property with validation should probably use a @Type decorator. If this is an enum use @IsEnum(). If this is a plain object use @IsObject().eslint[@darraghor/nestjs-typed/validated-non-primitive-property-needs-type-decorator](https://github.com/darraghoriordan/eslint-plugin-nestjs-typed/blob/main/src/docs/rules/validated-non-primitive-property-needs-type-decorator.md)

I feel like I am validating these correctly for what I need, but this rule is telling me to do something that I'm pretty sure I'm already doing

abrindam commented 3 months ago

Very coincidentally, I ran into the same issue within 12 hours of you! Small world...

In my case, I had a union type of literal values, so extending your example:

@IsNotEmpty()
@IsString()
Profile!: 'ZCATS' | 'XDOGS' | 'YBIRDS';

and was getting the same linting error even though @Type() is not appropriate.

I've opened a PR #188 as it turned out to be a pretty easy fix.

ChrisMBarr commented 3 months ago

Oh wow, well that's great! Perhaps another workaround would be that if you use the @Equals('foo') decorator then no others should be required - if you only care about specific values then the overall type doesn't really matter.

Would your PR also take care of #187 I opened yesterday as well?

abrindam commented 3 months ago

I think it will, I definitely fixed union types of literal strings, so I think union types of literal numbers is probably fixed as well!

darraghoriordan commented 3 months ago

:tada: This issue has been resolved in version 5.0.10 :tada:

The release is available on:

Your semantic-release bot :package::rocket: