Typescript upgrade

[Brian Lewis]

Currently using Typescript 1.8, which is a long way behind the current version 3.0

However, typescript upgrades tend to apply more stringent type-checking, so code remediation will be required to resolve issues that currently compile Ok.

Investigation suggests that we don't get issues as far as 2.3, but 2.4 introduces stronger checking on generic types, especially generic promises, that generates a raft of errors. However, there are also changes in the way it looks for .d.ts files ( after, 2 automatically in any node_modules/@types folder) that can create unexpected problems.

So why do we need to do it?

I'm finding that as we get new versions of 3rd party libraries, the supporting .d.ts files can be aimed at higher versions of the compiler, and this will leave us a bit stuck.

So I propose to remediate under typescript 1.8, then go up to 2.4 when changes are done; then move typescript forward from there in the future.

Here's one example that generates a class of errors that appear under typescript 2.4: in book.filter.ts

    public createFindConfig() {
      let config = new Sw.Filter.FindConfig();
      let d = this.$q.defer();

      ....

      config.identity.filter = this.identityFilter();
      config.reset();
      d.resolve(config);
      return d.promise;
    }

the return value d.promise above does not match the strongly typed promise in the interface this method implements. The solution is simple and needs to be applied in every xxFilter class:

    public createFindConfig() {
      let config = new Sw.Filter.FindConfig();
      let d = this.$q.defer<Sw.Filter.FindConfig>();

      ....

      config.identity.filter = this.identityFilter();
      config.reset();
      d.resolve(config);
      return d.promise;
    }

Many other problems come from routes, and this is a shortcoming of the ui-router.d.ts which does not accurately describe the IState interface - this I will fix with a tiny separate PR.

Bear in mind that in our project, the version of typescript used for compilation is the one referenced in the package.json in pineapples\client. this is because grunt is doing the compiling. However, the version of typescript used for intellisense is the version installed into Visual Studio; so these can be out of sync : if you are using VS 2015, go here

https://www.microsoft.com/en-us/download/details.aspx?id=48593

to get Typescript 2.4 installed in VS as well

[Brian Lewis]

@ghachey @jeremy_kells this is now merged; please let me know if you get issues.

Visual Studio should process the changed package.json when the project loads;you should then be able to verify that the compiler version has changed when you build the typescript.

Also you'll need to get the updated typescript package for your version of Visual Studio as I describe above.

I think we'll be glad of having this done going forward. Code compiles clean up to version 3.0 of typescript now, let's consider whether we want to goo up to the new version in the next few weeks; but 2.4 is a worthwhile modernisation for the reasons above.

[Brian Lewis]

pull request #205 resolves

[Brian Lewis]

@jeremy_kells Switching you comment re typescript version to here.

@ghachey in case you see the same behaviour

So the actual compiler used is set in package.json.

If you look in there it should say ~2.4.2

Cheap trick here - make this file dirty somehow, (delete a comma and type it again! then save. This should force Visual Studio to detect the change and reprocess package.json, You can see this going on in the output window if you select npm/bower tools in the dropdown.

Thereafter you should have typescript 2.4 and you can look in the node_modules folder to verify that it is indeed there.

See also the comments above about the Visual Studio version of typescript used for intellisense.