Type annotations are frequently ignored in --checkJs

[Zarel]

TypeScript Version: 2.3.2

Code

class Wrapper {
  constructor() {
    /** @type {boolean} */
    this.isThing = false;
    this.isThing = !this.isThing;
  }
}

Expected behavior:

This passes.

Actual behavior:

Every once in a while:

test.js(4,5): error TS7022: 'isThing' implicitly has type 'any' because it does not have a type annotation and is referenced directly or indirectly in its own initializer.

It's very inconsistent whether or not this error (and other similar errors) appears. It seems like being part of a larger project makes it much more likely.

Since this bug is much easier to consistently reproduce on larger codebases, I've pushed a commit that reproduces the bug in the context I hit upon it:

https://github.com/Zarel/Pokemon-Showdown/tree/e34c77930a7eaae05a28eb68cbc392c777b8c590

If you checkout this commit and run tsc, you'll get three errors which I believe are related:

sim/dex-data.js(101,3): error TS7022: 'exists' implicitly has type 'any' because it does not have a type annotation and is referenced directly or indirectly in its own initializer.

sim/dex.js(87,7): error TS2322: Type 'string[]' is not assignable to type '("Pokedex" | "FormatsData" | "Learnsets" | "Movedex" | "Statuses" | "TypeChart" | "Scripts" | "It...'.

Type 'string' is not assignable to type '"Pokedex" | "FormatsData" | "Learnsets" | "Movedex" | "Statuses" | "TypeChart" | "Scripts" | "Ite...'.

sim/dex.js(1476,33): error TS2531: Object is possibly 'null'.

(All three of them disappear when I copy/paste the relevant code into a new file to try to create a simple testcase, and all three are incorrect.)

Here's a screenshot of it failing in Visual Studio Code:

[mhegazy]

The compiler honors the type annotation, but since these are all assignments, it is not clear which one is the declaration, it still tries to evaluate the expressions. the assumption is that the right-hand-side of the assignment will have a type we can use, but here this.exists = !!(this.exists && this.id); it has a self reference, and that triggers the implicit any.

The solution here would be to give JSDoc higher precedence. this could mean doing two passes, one to find the JSDoc, and one to compute the expression if none was found.

[Zarel]

The other thing is that !anything should be boolean, so even with the self reference, it shouldn't need to trigger the implicit any, right?

Also, shouldn't it be clear that the first one is the declaration? I know TypeScript can handle variables being different types in different parts of the code. I've written code like:

/** @type {string | number} */
let a = ...;
if (typeof a === 'string') return;
// a's inferred type is now number

So when we get to this.exists = !!(this.exists && this.id);, even if it is a self-reference, TypeScript should know what type it is, shouldn't it?

[mhegazy]

Based on the discussion in https://github.com/Microsoft/TypeScript/issues/15747, @type should always have precedence. for contextual typings purposes, we need to first walk all the binary expressions we have, and see if any of them has a @type, then use that as a type, instead of checking the expression directly.