Add 'no instanceof' config switch

[AsherBarak]

The way instanceof works presents a potential pitfall for ts developers. An instance passing ts type check may (or may not) fail instanceof check depending on the way it was constructed:

class A {
    a: string;
}

let a1: A = new A();
let a2: A = { a: 'test' };

console.log(a1 instanceof A); // true
console.log(a2 instanceof A); // false

While this may not be avoidable given the relationship between js and ts, it might be useful to have the compiler enforce a policy where using instanceof is simply disallowed.

[kitsonk]

Since this is valid JavaScript and would be a coding convention, like using let or const over var, it would be best served by a linter rule than being baked into TypeScript, in my opinion. While TypeScript does dabble in erroring on certain patterns, like code after return, it generally constrains itself to code that is undesirable at runtime. While there are challenges with the structural type system of TypeScript and the instanceof operator, it is still the only valid way of narrowing certain types and constructs and has a role to play.

[DanielRosenwasser]

Agreed with @kitsonk - disallowing these sorts of constructs is not something we generally do.

[jcalz]

I assume instanceof is safe in this direction:

a1.a = 'hello';
function safe(x: any) {
    if (x instanceof A) {
        return x.a;  // safe
    }
    return 'who knows';
}
safe(a1); // 'hello'
safe(a2); // 'who knows'

but not safe in this direction:

function unsafe(x: A | string) {
    if (x instanceof A) {
        return x.a.concat('!');
    }
    return x.concat('!'); // not necessarily
}
unsafe(a1); // 'hello!'
unsafe(a2); // TypeError: x.concat is not a function

It would be nice if any linter warning didn't flag the first usage.

[kitsonk]

That would be up to the linter. tslint has access to the language services and could try to determine what sort of narrowing is going on, but it sounds rather complex, but the example does show perfectly safe use of instanceof in TypeScript. 😁

[AsherBarak]

@jcalz In your second example the difference between the way ts perceives A and the way js handles instaceof confuses the ts compiler to thinking the A case of the input parameter has already been handled. I did not think of that, and (@kitsonk, @DanielRosenwasser, @RyanCavanaugh) I think that is something that might be better handled in TypeScript compiler.
I was aiming to your first example and I think that, while being safe, its is misleading. A programmer might be surprised to learn that a perfectly good instance of A running around in his code returns who knows while others return the value of a.a. This, however, would probably be better as ts-lint rule palantir/tslint#2943