Class fields cause false positive no-undef

[ackvf]

What version of TypeScript are you using? 2.7.2, 2.8.1

What version of typescript-eslint-parser are you using?

15.0.0

What code were you trying to parse?

class X {
  field = {} // [eslint] 'field' is not defined. (no-undef)
}

What did you expect to happen? I did not expect any error

What happened? I get [eslint] 'field' is not defined. (no-undef)

[todorone]

@ackvf DId You manage to resolve this issue?

[ackvf]

No, I had to turn the rule off. It still reports false errors with latest 16.0.1. (typescript 3.0.0-dev.20180626)

[lostfictions]

I'm also experiencing this (typescript-eslint-parser 17.0.1). Unfortunately, we're currently in the process of converting our codebase to TypeScript, so we have a mix of JS and TS files and it's not acceptable for us to turn no-undef off.

Unfortunately, seems like we'll simply need to revert to babel-eslint for the JS files and use TSLint instead for TypeScript.

[ackvf]

@lostfictions @todorone The undef property is still covered by tslint if you use both (like I do).

[todorone]

@ackvf Thanks for the hint. I don't want to introduce tslint in my project so I just had to turn this rule off...

[timche]

Check no-undef with tsc instead until this issue has been resolved:

1. Disable no-undef in ESLint
2. tsc will now error at not defined variables

Edit: Fixed my comment based on @lostfictions answer.

[lostfictions]

@timche sounds like you might be thinking of no-unused-vars, which is a different rule (which also sees lots of false positives with this parser and can be turned off in favour of TS rules noUnusedLocals and noUnusedParams, it's true.) This is a separate issue.

@ackvf It's true that no-undef is not required for TypeScript files -- the compiler handles it, no linter necessary. What I was trying to articulate is that in a project with mixed TypeScript and vanilla JavaScript files, it's not acceptable to turn off no-undef for the entire project, because then undefined variables in the JS files would not get caught by the linter.

In the end we set up a second eslint config file that turns these rules off for only the TS files and keeps it on for JS files (with a different parser). But having multiple config files means we lose ESLint editor integration for TS files, which is a big blow to productivity. So we may still switch to TSLint, since at least TSLint and ESLint can run side-by-side in VS Code, whereas there doesn't seem to be a way to make vscode-eslint handle two different file extensions with different config files.

[timche]

@lostfictions You are right, I'm confusing it with no-unused-vars.

There are currently two rules I've disabled in ESLint:

• no-undef
• no-unused-vars

Both are causing false-positives in ESLint with typescript-eslint-parser.

By deactivating them, we now let tsc check them:

• no-undef: No configuration required
• no-unused-vars: "noUnusedLocals": true in tsconfig.json

[Gvozd]

@timche no-unused-vars can be replaced with typescript/no-unused-vars from eslint-plugin-typescript