Slow incremental compilation with watchify

[kuon]

I use tsify with browserify and watchify.

While it works, it is slow. If I have a simple "hello world" js file, it takes 1 to 3 seconds to recompile it when I save it.

I do not know if this is an issue with tsify or watchify, but tsc -w is much faster (about 100ms to recompile)

[martijnarts]

+1

Since this issue is almost a month old, I'm gonna look through the watchify and tsify source a bit to see if I can fix it myself and make a pull request because the recompilation speed is atrocious.

[smrq]

Thanks for looking into it, hope you find something useful

[henrify]

You probably already know / do this, but keeping external/vendor dependencies that don't normally change in separate bundle can speed things up by order of magnitude.

[chrismatheson]

We are using this plugin on a large codebase that is being slowly converted to TS.

Currently we are at a build time of ~2m30s from standing start and a more reasonable ~15s for incremental watchify build.

we have a few engineers here and would be happy to dedicate some time to fixing this. Are there any pointers / directions / know performance bottle necks that can be attacked. Im going to try and start gorking this module now but would appreciate any input :)

[kuon]

But here is a starting point:
https://github.com/Microsoft/TypeScript/wiki/Using-the-Compiler-API#incremental-build-support-using-the-language-services

More specifically, this:
https://github.com/TypeStrong/tsify/blob/master/lib/Tsifier.js#L122

should be changed to use the ts language services, those services should be cached between run of the tsify:

const services = ts.createLanguageService(servicesHost, ts.createDocumentRegistry())

must be kept between invocations of the tsify plugin.

This is without warranty, only the result of my first look into this. At the time I didn't have the time to work on it.

[jbrantly]

There's quite a bit of information on this over at TypeStrong/ts-loader#78. It's still an open issue for ts-loader as well, which does use the language service. The main slow point for incremental builds turned out to be collecting all of the various errors, because even though you only need to get the output for the changed file, you need to collect errors for all affected files which in the simple case just means collect errors for all files.

In any case, I'm not sure that using language services is necessarily the fix. I believe that tsc -w does not use the language service. I've been meaning to see if I could fix the performance problems in ts-loader by trying to model it after tsc -w but haven't had a chance yet. I'll be interested in any results that come out of this thread.

but tsc -w is much faster (about 100ms to recompile)

How were you able to time that?

[kahlil]

Hi! So in my tests compiling a simple Angular 2 project with tsify takes around 11s instead of 2s with babelify and recompiling with watchify takes 3s. Instead of 60ms with babelify. tsc -w also only takes a few ms. So far tsify does not seem to be a viable alternative to tsc -w and System.js.

[ksikka]

If anyone wants to try an easy fix that's probably incorrect in a lot of cases, but will likely cut incremental compile time in half:
master...ksikka:perf-fix

I don't have access to a codebase large enough to test it myself, but I generated a bunch of TS code and this fix does cut down the incremental compile time significantly on my highly unrepresentative test case. That said, it's also probably incorrect, not taking into account new typescript files and other edge cases that I don't have the time or resources to look into.

Good luck!

[stefan-leye]

I have the same problem with watchify and tsify, taking around 3 seconds to compile everything.

[kahlil]

My strong recommendation is to just use tsc on the command line to compile your TS to ES5 with CommonJS modules and then have Browserify take over. It's really fast and works well.

[Avol-V]

@kahlil What about sourcemaps?

[OliverJAsh]

Can you input a source map to browserify?

[levibotelho]

@OliverJAsh It's unclear http://stackoverflow.com/questions/32486196/preserve-original-sourcemap-with-browserify but I've asked the question to clarify browserify/browserify#772. I'm currently doing what @kahlil is doing and wanted to use sorcery to combine my maps from compilation with my maps from bundling. However I run into this issue when getting sourcemaps from the compilation step gulp-sourcemaps/gulp-sourcemaps#211 where it doesn't combine sourcemaps from the TS and React steps correctly.

I hope that I can get a solution to the gulp-sourcemaps issue but for now am just sticking with sourcemaps from the bundling step. I'm left with compiled TS and JavaScript React invocations instead of JSX, but it's good enough for now and the incremental build speed gains make it worthwhile.

[kahlil]

@Avol-V yeah we realized that too. They don't work. gulp-sourcemaps does not load them or read them, whatever. The whole gulp/browserify setup became too complicated so we switched to Webpack for JavaScript building. That turned out to be the simplest and least work intensive solution.

It is really quite straight forward basically you just tell Webpack: take TS files from here and transform them to JavaScript there, and please also produce sourcemaps. Thank you.

And it just works.