@babel/eslint-parser false positive for no-unused-vars rule with TypeScript types

[taylankasap]

Bug Report

• [x] I would like to work on a fix!

Current behavior @babel/eslint-parser gives false positive (shows error) for no-unused-vars rule with TypeScript types:

error  'Rubik' is defined but never used  no-unused-vars

Input Code

import Rubik from './Rubik';

export default class Arranger {
  private readonly rubik: Rubik;
}

Expected behavior When run eslint, no errors/warnings should arise.

Babel Configuration (babel.config.js, .babelrc, package.json#babel, cli command, .eslintrc)

• Filename: babel.config.js

{
  "presets": [
    "@babel/preset-env",
    "@babel/preset-typescript"
  ],
  "plugins": [
    "@babel/proposal-class-properties"
  ]
}

• Filename: .eslintrc.json

  {
  "parser": "@babel/eslint-parser",
  "rules": {
  "no-unused-vars": ["error"]
  }
  }

Environment

  System:
    OS: Linux 4.19 Alpine Linux
  Binaries:
    Node: 12.18.3 - /usr/bin/node
    Yarn: 1.22.4 - /usr/bin/yarn
  npmPackages:
    @babel/core: ^7.10.2 => 7.11.4
    @babel/eslint-parser: ^7.11.4 => 7.11.4
    @babel/eslint-plugin: ^7.11.3 => 7.11.3
    @babel/plugin-proposal-class-properties: ^7.8.3 => 7.10.4
    @babel/preset-env: ^7.10.2 => 7.11.0
    @babel/preset-typescript: ^7.9.0 => 7.10.4
    eslint: 7.2.* => 7.2.0
    webpack: ^4.43.0 => 4.44.1

Note This issue already existed before switching to Babel monorepo (in babel/babel-eslint) so the switch is not the cause.

[babel-bot]

Hey @taylankasap! We really appreciate you taking the time to report an issue. The collaborators on this project attempt to help as many people as possible, but we're a limited number of volunteers, so it's possible this won't be addressed swiftly.

If you need any help, or just have general Babel or JavaScript questions, we have a vibrant Slack community that typically always has someone willing to help. You can sign-up here for an invite."

[kaicataldo]

Sorry for missing this. Have you tried the @typescript-eslint/eslint-plugin version of this rule to see if it fixes the issue you're describing here?

[taylankasap]

No worries.

Are you implying that plugins in @typescript-eslint/eslint-plugin can be used with @babel/eslint-parser? (I've just tried and couldn't manage to get them to work together.) Or are you just asking if it works with the @typescript-eslint/parser? If so, it works with that parser even without using any plugins. (Although the plugin is still better because it also works with TypeScript enums, but that's not the issue right now).

[prateekbh]

I tried this with @babel/eslint-parser but it still reports the imports made only for types as unused variables.

[kaicataldo]

@taylankasap Sorry, should have clarified - I meant in conjuction with @typescript-eslint/parser. We've left linting TypeScript to @typescript-eslint due to all the duplicated work and lack of type information that actually using tsc gives you (i.e. @typescript-eslint/parser rules can actually access type information!). The assumption is that if you're running tsc over your files, @typescript-eslint/parser will be able to lint it. If you're doing some sort of two pass transformation (transforming syntax features not supported by TypeScript with Babel and then running tsc), that's currently not a supported use case.

[taylankasap]

In that case it's all good.

Maybe this part can be mentioned in readme or docs:

We've left linting TypeScript to @typescript-eslint due to all the duplicated work and lack of type information

Anyway, thanks for the info.

[prateekbh]

@kaicataldo does that mean for typescript we should still use @typescript-eslint/parser? and not @babel/eslint-parser

[kaicataldo]

@taylankasap That's a good idea!

@prateekbh That's right!