TypeScript 2.0 for dojo/compose

[Kitson Kelly]

[Kitson Kelly]

I took a first stab at migrating to TS2 for dojo/compose.

• this typing helps out a lot
• There are some issues open with the TypeScript team (#8367, #8368, #8370, and #8373)
• readonly is available, but also inferred. The inferred this typing in object literals is powerful, but can cause some things that worked before to break as this in object literals is not always any.
• Was able to remove a lot of casting in places, though the inferred lack of an index signature can be annoying (but in theory accurate).

[Kitson Kelly]

And it is all in the tsnext branch.

[Kitson Kelly]

I enabled strictNullChecks which is a feature I think we want. It helps validate that we are using objects in a safe way and helps avoid common mistakes.

There is one issue with this (see #8396) but it is easily worked around. There is a little bit of awkwardness in tests, partly because tests often check to make sure things aren't broken, potentially accessing things in a "risky" way. Also, currently grunt-ts does not recognise the compiler flag, so I had to make some changes there to allow the tsconfig.json to pass through unaltered.

[Kitson Kelly]

Ok, with #8370 fixed, I think the tsnext branch is ready for the release of TS 2.0. I made some final changes to take advantage of that. The remaining issues are either fixed, or changes in behaviour that no longer directly impact that code.

[Kitson Kelly]

We should check this against the beta. I think a few things have changed.

[Kitson Kelly]

A couple of minor things when dealing with strictNullChecks and the introduction of the never bottom type. For example, it is "bad" to copy an array this way:

[].concat(sourceArray);

Because TypeScript can only infer never[] as the type for the array. Of course you can cast it and it works fine, but that isn't ideal. Instead I guess we should use the from polyfill from dojo-shim:

import { from as arrayFrom } from 'dojo-shim/array';

arrayFrom(sourceArray);

And in that case, the typing is correctly inferred.

[Kitson Kelly]

I have also enabled noImplicitThis which I think is a good idea. This is like noImplicitAny which we already use, but if we access this in a function and the value of this cannot be inferred contextually, it will throw an error, ensuring that you properly type this.

The other interesting thing that I have found is that TypeScript will also guard against calling a function where this is typed if that does not match the type constraint, which is pretty powerful in avoiding errors.