Removal of type-checking support

[frankwallis]

From version 7.0.0 onwards, plugin-typescript no longer supports type-checking, files are now only transpiled and the plugin will report on syntax errors but will not report any type-checking errors. Here I want to record the reasoning behind this and open it up for discussion.

typings - it was not possible to match the typescript compiler's file resolution algorithm in the browser as it can involve searching the file-system for external typings files included in packages.
@types - again typescript searches the file system to find declaration files in @types packages, this is not possible when compiling in the browser.
wildcards - tsconfig now supports specifying wildcards for files to be included in the build.
fetch - in order to type-check a file the plugin needs to fetch declaration files and elided typescript files outside of the runtime javascript dependency tree. SystemJS no longer supports fetching files and other ways of injecting these files can affect the order that files are actually executed at runtime.
complexity - the added complexity needed to support type-checking was having a negative impact on transpiler support, for example it was hard to introduce package-level typescriptOptions which is now available in 7.0.0.

Ultimately it was impossible for plugin-typescript’s type-checking to maintain parity with other typescript tooling and tsc itself. Because of the incompatibility with other tools, type-checking with plugin-typescript was no longer a setup I felt comfortable supporting and recommending to others. My advice is to use npm @types and perform type-checking in the IDE and using tsc itself, and use plugin-typescript to get a fast turnaround when developing in the browser.

I hope that 7.0.0 will be a strong and stable release and I welcome any feedback.

[aluanhaddad]

@frankwallis thanks for the clear statement. Personally, I use this mostly for transpilation only, and rely on my IDE for type checking, so it is not a major issue for me.
For what it is worth, when I have to use Webpack (peers can be stubborn), I disable type checking for ts-loader/awesome-typescript-loader as well because I feel it mixes too many concerns and slows transpilation on large projects.

I know many will be upset however, and while I think this could maybe ultimately be worked out, it would be, as you say, only at an incredibly high complexity cost.

It is a shame about fetch!

That said, I hope that being able to focus on this more minimal functionality will ultimately lead to improved performance (which by the way is quite good already)

On a side note, I am really happy hear that

package-level typescriptOptions

is implemented, that is truly awesome. I am sorry I did not have the time to help with this feature as I had originally intended.

I will continue to use this awesome plugin.
Keep up the fantastic work!

[bennadel]

Thanks for the insight. I tripped over this today when I tried to upgrade my plugin and saw that typeCheck:true was no longer supported. I use this plugin to run my Angular2 demo in TypeScript, so I used the in-browser transpiling and type-checking to ensure I was doing everything correctly.

I guess in the future, I will just have to do all my compiling offline and use a distribution file for my demos.

[tamird]

Yikes, this is a sad step backwards. As best I can tell, this is the end of JSPM+TS entirely in browser; all projects will now need to support builds both in the browser and with tsc.

[bennadel]

For what it's worth, after learning this, here's the solution I came up with to run tsc offline, but still use System.js to do the rest of it. It was the most simple stop-gap that I could come up with.

https://www.bennadel.com/blog/3240-building-javascript-demos-with-system-js-typescript-2-2-1-and-angular-2-4-9.htm

[adelespinasse]

As someone who's new to Typescript but has been using jspm for a while, this was really confusing to me. I assumed type errors would show up in the JS console, and I spent some time trying to figure out what I was doing wrong. Finally I decided it was probably a bug in plugin-typescript, and came here to file it, which is when I discovered this issue.

I suggest adding a prominent note in the main README.md saying that type checking isn't supported. Probably also in jspm documentation (though I think there currently isn't much of anything covering Typescript usage).

It might also be nice to add suggestions on how to configure an alternative method of type checking. I guess you pretty much have to configure a tsserver or something from scratch, but I haven't yet learned how to do that, and maybe there's a pretty simple series of steps that works for most jspm projects.

[aluanhaddad]

@adelespinasse I definitely agree that documentation could be better on the JSPM side of things. As far as setting up typescript to do type-checking, this is what I use

> tsc --watch --noEmit --project tsconfig.json

The --noEmit flag tells TypeScript to run a typecheck only.

If you need multiple independent watch tasks, concurrently works well.
For example, in package.json

{
  "scripts": {
    "start": "npm run concurrently \"tsc --noEmit -w -p tsconfig.json\" \"tslint -p tsconfig.json -c tslint.json\" \"jspm bundle -wid app\""
  }
}

Note: You will likely want an npm install of TypeScript (can be global) in addition to the version installed as a dependency of plugin-typescript by JSPM.

[adelespinasse]

I was using a tsserver-backed IDE plugin to do type checking, and I had trouble getting it to be able to find jpsm-installed npm modules. It was giving a lot of "can't find module React" type errors. There are things I haven't tried yet, but if you have a tsconfig.json that works for you, I'd love to see it.