TL;TR

A lot of developers put return  into conditional statements, and often don’t consider all cases because the function implicitly returns undefined which is fine for TypeScript: not a problem apparently, but can lead to unexpected results.

The domain

As it turned out from my previous post, in TypeScript every type is nullable: this means that for every type null and undefined are valid values.
Not to mention the notorious any, which fits any type well.

The problem

Going a bit further we can easily realise that given a function (string) => number like

the compiler will not complain about it even if actually my function is returning (number | undefined).

And a block which is using that function like, for instance

will end up with NaN as a result: the names array is accepted with both null and undefined, and since the function countCharacters is implicitly allowed to return undefined our code is applying the operator + to different types which results in NaN. The result makes totally sense, but probably is not what you expect to get.

The bottom line

Nonetheless seems impossible to check against such errors as of 1.8, because for TypeScript this is not a problem but rather a feature: thanks to type nullability it is compiling even against legacy codebases and moreover allows the average developer to write code before thinking.

There are some proposals to fix it like a compiler’s options or an identifier but as of today we can only use run time assertions, a strict linter and force our fellows to read Douglas Crockford.

One good alternative is to switch over Flow.