Skip to content

[consistent-type-imports] add support for passive value usage by decorators when emitDecoratorMetadata is enabled #2559

Closed
@vegerot

Description

@vegerot
  • [x ] I have tried restarting my IDE and the issue persists.
  • [ x] I have updated to the latest version of the packages.
  • [x ] I have read the FAQ and my problem is not listed.

Repro

{
  "rules": {
    "@typescript-eslint/consistent-type-imports": 'error'
  }
}
import {
  Controller,
  Logger,
} from '@nestjs/common';
import { ConfigService } from './config/config.service';
import { UserSessionRepository } from '../entities/user-session/user.session.repository';
import { UsersService } from './users/users.service';
import { AuthService } from './auth/auth.service';

Expected Result
I expected the result to work

Actual Result
It "fixes" the code to

import {
  Controller,
} from '@nestjs/common';
import type { Logger } from '@nestjs/common';
import type { ConfigService } from './config/config.service';
import { UserSessionRepository } from '../entities/user-session/user.session.repository';
import type { UsersService } from './users/users.service';
import type { AuthService } from './auth/auth.service';

This causes errors like

Error: Nest can't resolve dependencies of the AppController (?, Function, Function, Function, UserSessionRepository). Please make sure that the argument Function at index [0] is available in the RootTestModule context.

Potential solutions:
- If Function is a provider, is it part of the current RootTestModule?
- If Function is exported from a separate @Module, is that module imported within RootTestModule?
  @Module({
    imports: [ /* the Module containing Function */ ]
  })

I want to say I know this is Nest's problem and not ESLint's. The linter is correctly identifying this import is only used in a type context. But for reasons I really dislike about Nest.js, they use this information in their dependency injection process.

This thread is not really to report a bug, but to ask for advice on how to proceed? Would there be the potential to add an option to consistent-type-imports to regex types not to fix (where I could put my Services)? Or should I just not use this rule in any Nest projects?

Versions

package version
@typescript-eslint/eslint-plugin 4.1.0
@typescript-eslint/parser 4.1.0
TypeScript 4.0.2
ESLint latest
node 14

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestpackage: scope-managerIssues related to @typescript-eslint/scope-manager

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions