no-unused-variable does not recognize destructuring assignment

[jnu]

Bug Report

• TSLint version: 3.6.0
• TypeScript version: 1.8.9
• Running TSLint via: SublimeLinter

TypeScript code being linted

class Foo {

  private bar: string = 'bar';

  public method(): void {
    const { bar } = this;
    console.log(bar);
  }

}

with tslint.json:

"no-unused-variable": true

Actual behavior

Error: unused variable: 'bar'

Expected behavior

should detect that bar is used through destructuring assignment

[jkillian]

Hi @jnu, the warning comes because of the line:

private bar: string = 'bar';

That bar, is in fact, unused. 😉

[jnu]

what? yes, it is used.

compare the semantically equivalent:

class Foo {

  private bar: string = 'bar';

  public method(): void {
    console.log(this.bar);
  }

}

there is, correctly, no lint error in this case. the linter appears not to be catching that bar is used through destructuring assignment.

[jkillian]

Whoops, my bad! I just skimmed your code for this.bar and wasn't really paying attention to how you were in fact using it...

[jnu]

:) thanks!

[jkillian]

So this is actually a somewhat complicated issue... the tricky thing there is that the bar in const { bar } = this actually refers to two things: the identifier of the field on this and the identifier of the local variable it creates.

To determine if a variable is used, we use an API of TypeScript that finds all the references to an identifier. (This is the same API that atom-ts or vscode uses when you select a variable and choose something like "find references").

This is a confusing scenario, because it can be unclear what should happen. And in fact, there are many TS issues about similar situations:

microsoft/TypeScript#6459
microsoft/TypeScript#6312
etc.

There's been a recent PR that loos helpful and suggests that this situation may have been fixed: microsoft/TypeScript#7945

Essentially this is an issue that we just have to hope changes in TS, which will fix things here in TSLint. If there's a definite bug in TS (even given the changes above), I'll file an issue with them.

[jnu]

great, thanks for looking into it!

[andy-hanson]

Should be fixed by #2235.