darraghoriordan / eslint-plugin-nestjs-typed

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

`validated-non-primitive-property-needs-type-decorator` totally errors out for `unknown`, `any`, and `object` types #184

Closed ChrisMBarr closed 48 minutes ago

ChrisMBarr commented 6 days ago

In a DTO, using a type of Array<unknown> or Array<any> or Array<object> completely errors out this rule

Oops! Something went wrong! :(

ESLint: 8.57.0

TypeError: Cannot read properties of undefined (reading 'type')
Occurred while linting C:\Users\<my-repo>\src\time-api\dto\post-records.dto.ts:30
Rule: "@darraghor/nestjs-typed/validated-non-primitive-property-needs-type-decorator"
    at PropertyDefinition (C:\Users\<my-repo>\node_modules\@darraghor\eslint-plugin-nestjs-typed\dist\rules\validateNonPrimitiveNeedsTypeDecorator\validateNonPrimitiveNeedsDecorators.js:159:50)
    at ruleErrorHandler (C:\Users\<my-repo>\node_modules\eslint\lib\linter\linter.js:1076:28)
    at C:\Users\<my-repo>\node_modules\eslint\lib\linter\safe-emitter.js:45:58
    at Array.forEach (<anonymous>)
    at Object.emit (C:\Users\<my-repo>\node_modules\eslint\lib\linter\safe-emitter.js:45:38)
    at NodeEventGenerator.applySelector (C:\Users\<my-repo>\node_modules\eslint\lib\linter\node-event-generator.js:297:26)
    at NodeEventGenerator.applySelectors (C:\Users\<my-repo>\node_modules\eslint\lib\linter\node-event-generator.js:326:22)
    at NodeEventGenerator.enterNode (C:\Users\<my-repo>\node_modules\eslint\lib\linter\node-event-generator.js:340:14)
    at CodePathAnalyzer.enterNode (C:\Users\<my-repo>\node_modules\eslint\lib\linter\code-path-analysis\code-path-analyzer.js:803:23)
    at C:\Users\<my-repo>\node_modules\eslint\lib\linter\linter.js:1111:32

Here's some example code that causes it to fail

class Fail1 {
  @IsArray()
  @IsNotEmpty()
  @ArrayNotEmpty()
  Foo!: Array<unknown>
}
class Fail2 {
  @IsArray()
  @IsNotEmpty()
  @ArrayNotEmpty()
  Foo!: Array<any>
}
class Fail3 {
  @IsArray()
  @IsNotEmpty()
  @ArrayNotEmpty()
  Foo!: Array<object>
}

But changing to use a more "normal" type allow the rule to not break... but of course now it doesn't match my usage in the app.

class Success{
  @IsArray()
  @IsNotEmpty()
  @ArrayNotEmpty()
  Foo!: Array<string>
}

This should not break the rule, even if the rule can't make a good recommendation here.

darraghoriordan commented 3 days ago

probably easier just to disable the rule for these cases. But feel free to submit a PR if you get a chance

ChrisMBarr commented 3 days ago

It's not possible to disable the rule on a per-line or even a per-file basis since it throws errors due to it not being able to parse my code. The only solution is to disable it entirely for the project for now