Suggestion: --noImplicitBooleanConversion

[buola]

Typescript forbids automatic conversion to boolean in function calls, which makes sense, since there's actually no coercion in the generated typescript code when passing a non-boolean argument to a function taking a boolean. The Javascript function would receive a non-boolean.

However, it allows coercion to boolean in 'if', 'while', 'for' and 'operator !'

This can lead to hard-to-find bugs, such as:

//Prints number and/or array, when given
function f(n?: number, a?: number[]) {
  if(n) console.log(n); //there is a bug here, should be if(n!==undefined)
  if(a) console.log(a); //this is okay
}

f(1); //prints 1
f(1, []); //prints 1 and []
f(undefined, [0]); //prints [0]
f(0, [0]); //only prints [0]!!!

Proposal
Reduce the likelihood of such bugs, by adding a flag --noImplicitBooleanConversion that will make the following expressions illegal:

if(a) {}
if(!a) {}

when a has the type 'number | undefined' or 'string | undefined' (and possibly more involving 'null' or combinations of 'number' and 'string')

I also suggest that in this case, the coercion can be forced with:

if!(a) {}
if!(!a) {}

which are then legal.

Coercion to boolean of variables where the type is just 'number' or 'string' would always remain legal.

Further discussion

The above only addresses one very common pattern, and doesn't address the expression !a outside of the if context. Finding a suitable "override" syntax might be challenging (the equivalent of if! for the above case).
It also doesn't address expressions like 'a && f(a)', 'a || 5' or '(a ? a : 5)', which might also produce unexpected results when a is of type 'number | undefined'. These could be explored.

[buola]

I realized that the override syntax might not be necessary, since even if '!a' was made illegal when 'a' is of type 'number|undefined', '!a!' would be legal, and a suitable override. 'if(a!)' would also be legal, and generate identical code to 'if(a)'.
The only case where it might produce an unexpected result is in expressions like 'a! && 5', which has type 'number', while 'a && 5' has type 'number | undefined'

[RyanCavanaugh]

This is too idiomatic to ban everywhere, even under a flag (flags are not free and need to justify their existence). The TSLint rule mentioned above is the right place to disallow idiomatic JS expressions.