TypeScript files often produce a false positive about "already declared in the upper scope"

[kaiyoma]

I want to report a bug.

I'm actually quite shocked no one else has reported this, given how often we run into it. SonarQube analysis of many of our TypeScript files usually produces one or two of these kinds of code smells:

'foo' is already declared in the upper scope.

The code smell is always incorrect because the variable is not declared anywhere else, nor does that identifier appear anywhere else. It's actually quite the mystery why this rule is getting triggered.

SonarTS version: 2.1 (build 4359) Node.js version: 12.16.1 TypeScript version: 3.8.3 SonarQube version: 7.9.2.30863

Rule key: It's not apparent where to get this. Provide some instructions in the template maybe?

Reproducer Here's a sanitized snippet of one of the files triggering this rule incorrectly:

import { a, b, c } from 'package-one';
import { d } from './local-file';

interface I {
  e: string;
  f: string;
  g: string;
}

function foo(arg: string): I {
  if (!d.test(arg)) {
    process.stdout.write('some error string');
    process.exit(1);
  }

  const { h, g, i, j } = new URL(arg);

  ...

In this example, SonarQube incorrectly reports:

'g' is already declared in the upper scope.

Even though it's clear that g is not defined anywhere else.

[ed-graham]

We are also finding quite a lot of these. Some can be explained, though; for example:

const book= store.books.find(
      book => book.id === session.bookId
    );

Here the fix is quite simple - replace the inner book variable with something else:

const book= store.books.find(
      b => b.id === session.bookId
    );

[vilchik-elena]

Hey,

Since SonarTS 2.0 typescript code is analyzed by SonarJS (SonarTS is basically empty plugin). To avoid any confusion, it's easier to report your problems in https://community.sonarsource.com/, where our team is monitoring the new threads.

About your problem, it's a ESLint rule no-shadow which is run under the hood. Probably it does not work properly for TypeScript files.

I didn't manage to reproduce your mysterious FP @kaiyoma

@ed-graham I believe your case is valid, nothing to improve here.