Repository navigation
Slow incremental compilation with watchify #54
Description
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)
Activity
martijnarts commentedon Jul 2, 2015
+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 commentedon Jul 9, 2015
Thanks for looking into it, hope you find something useful
henrify commentedon Sep 10, 2015
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 commentedon Jan 11, 2016
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 commentedon Jan 11, 2016
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 commentedon Jan 11, 2016
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 -wdoes 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 aftertsc -wbut haven't had a chance yet. I'll be interested in any results that come out of this thread.How were you able to time that?
khalillechelt commentedon Apr 21, 2016
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 -walso only takes a few ms. So far tsify does not seem to be a viable alternative totsc -wand System.js.ksikka commentedon May 25, 2016
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 commentedon Jun 15, 2016
I have the same problem with watchify and tsify, taking around 3 seconds to compile everything.
khalillechelt commentedon Jun 15, 2016
My strong recommendation is to just use
tscon 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 commentedon Jul 7, 2016
@Kahlil What about sourcemaps?
OliverJAsh commentedon Jul 16, 2016
Can you input a source map to browserify?
levibotelho commentedon Jul 16, 2016
@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.
khalillechelt commentedon Jul 21, 2016
@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.