react-redux-typescript-jspm-starter: Typescript compile has errors (using the tsc version in the starter kit)

I’ve also tried vscode which have the same limitation AFAIK. Webstorm has a few features that I find it hard to get by without, like optimize imports and auto-resolve import for es6 modules. I haven’t tried atom lately, will give it a spin again.

Anyway, getting a bit derailed here 😃. The point was that regardless of your choice of IDE you should also be able to do a simple tsc in the terminal without getting any compile errors.

On my team we use a mix of Webstorm, Sublime and vscode. They all have plug-ins for typescript but they can be a bit flaky. So even if the IDE is reporting one thing, running tsc may say something else. Running tsc also becomes the least common denominator for all members of the team, regardless of which IDE they use.

By hidden error I mean that if you clone this repo today and just run a simple tsc you will get 50+ compile errors. But I am guessing that you don’t see these errors in your IDE. Thus the errors are “hidden”. Even if you get errors from tsc, you may still be able to build and bundle the project using third party tools (jspm, webpack etc). But I would not feel comfortable deploying something that gives errors when compiling in tsc.

I think this repo is a really good starting point. I would star it twice if I could 😃. I tried to set something like this up about a year ago but I had a hard time making it work so I went with webpack instead. I think people may clone this repo, run tsc, see a bunch of errors and draw the conclusion that it is broken (see for example #13). This would be a shame since the workflow this repo sets up is really nice. So what my PR is trying to do is to get a freshly cloned repo to compile without errors in tsc. The reason I setup tsc as an npm script is becuase it will then use the tsc installed locally in the project’s node_modules, rather than the one installed globally (again see #13).

Maybe not related but I think the key to understanding the usefulness of the flow this repo sets up is that it is OK that the typescript files are not fully compiled and type checked in the browser. It would actually be OK to just strip the types (if you target es6). The reason that it is OK is that you have something running elsewhere doing the full checking, such as tsc --watch. This way you get really fast iterations with hot-realoading but can still have full checking in the background.

Regarding “subset of the typescript compiler” I did not mean the API does not expose the ability to do full project compile same as tsc. I am no expert on the API but I think plug-ins could do a full project compile like tsc if they wanted to but usually do a smaller check than tsc in the interest of speed. Also tools using the API can sometimes do more, for example typescript-loader for jspm could use the path mapping feature before tsc was using it. Another difference is that I think most IDE plug-ins only check single files, while tsc --watch always checks all files “for correctness”.