Fast (incremental..?) build in Eclipse?

[appcortez]

When using a multi project workspace after each save in a "ts" (or even in an "html" source) file the build takes almost a minute and the nodejs process at OS level takes ~1.3Gb of memory... I tried the same build in the command line and it takes similar time (but at least less memory...). The only workaround I could figure out is to disable the TypeScript builder and create a custom builder to the project (with "tsc" based on your Wiki page) with the "--watch" option and so the build is already incremental at files system level in the background and takes just a second. But I have ~35 projects in my workspace and I am not sure this could work for every project... Is there a better way to have multiple TS projects with a fast (incremental) auto build..?

[derekcicerone-zz]

When you hit save, the builder is usually checking all downstream projects for errors in addition to compiling. If there are a lot of files and a lot of dependencies, I could see that leading to pretty lengthy build times. When you hit save, how long before the file is actually saved to disk? If I remember correctly, the file save occurs right away and then the check for errors runs which might take much longer.

[appcortez]

If I just put a space and save the TS file the save and the compile happens almost immediately... (The according js file appears in the target directory) but then the Eclipse statusbar says "Building workspace (5%)" for almost a minute. The NodeJs process is at 1.3Gb of RAM and the CPU is ~30%... I don't know what is it doing and why is the NodeJs process at 1.3Gb.. The "Progress" window in Eclipse says nothing special just the "Building workspace". I tried to run Eclipse in debug mode with trace level log but nothing additional info came up. Is there a way to debug the plugin what is it doing at this time? BTW: I was wrong there are 89 projects in the workspace and the projects are both Java and TypeScript projects at the same time. Maybe it's building all projects all the time?! If I delete all "js" files in the target directory and modify just the one TS source all other TS sources will be compiled to JS in the whole project. And this process is triggered as well when I just modify a simple html file in this project... It would be great to have an incremental build mode in your plugin which would work just like my workaround with the custom compiler + "watch mode" tsc. Is it possible?

[derekcicerone-zz]

Cool, that sounds right - although the message in the status bar doesn't change, the compilation step is usually very fast (well under a second). You should be able to load up code as soon as you save changes. The additional time spent "building" is just looking for errors (which is considered "building" to be consistent with Java's feedback).

Java projects shouldn't affect compilation times.

There already is incremental compilation support - that's why the new file is saved almost immediately.

[appcortez]

Ok, than the compile phase looks OK but why the NodeJs process is activating after this with such intensity? I checked now and even just modifying (putting one space somewhere) and than saving a Java source file triggers this NodeJs process to start and run for almost a minute and during this time Eclipse is blocked to any further save/compile action which is annoying if you have to work in 2-3 different sources with just tiny modifications which is frequently the case with webapps I guess. So is it possible to skip this phase or put it in the config? BTW: is it a plugin level thing or Eclipse produces it?

[derekcicerone-zz]

The Eclipse plugin is calling into the same language services used by tsc. Checking for errors is apparently pretty expensive.

Is Eclipse blocked while building? I thought it would still work until you tried to do a second operation perhaps? I've actually never worked on a project that took so long during the error-checking portion of the build.

It would probably be possible to modify the code to opt-out of error checks but I think that would kinda defeat the purpose of using TypeScript so probably not desirable to add that functionality.

[appcortez]

But what kind of error checks are there if the compile phase is already done in a sec? And why the node process takes 1.3Gb of RAM constantly? Are the 89 projects too much..? Is there maybe a way to have a more detailed log about this phase? Or it just compiles the whole workspace again? But then why would it be incremental? And why saving a non-TS source (java, html) triggers this process?

Maybe there could be 2 type of compiling: a) the (one) file based: when only 1 TS file is modified and saved -> compiling only that file b) project based: when the whole project and even the depending projects would be compiled

[derekcicerone-zz]

These are mostly good questions for the TypeScript team but I'll do my best to answer:

• the quick compilation times (writing the JavaScript file to disk) is due to it being a very simple operation - it just takes the TypeScript and converts it to JavaScript
• error-checking is much more difficult because it entails looking at the types across all the projects dependent upon the project which changed and ensuring that everything is still correct
• to be honest, 89 projects sounds like too many - you'll likely want to break things down into independent libraries so that 89 projects do not need to be loaded simultaneously (for example, the biggest project I've ever worked on had ~20 projects)
• I don't think there are more detailed logs but you could try debugging into the code - the error checking is mostly in the TypeScript language services so it would require logging on the NodeJS side
• actually writing files to disk is incremental - error-checking by necessity needs to look across the entire workspace. I'm not aware of a way to make the error-checking be incremental at this time
• saving non-TS files should not trigger a TS build - that sounds like a bug or something else weird going on

I'm actually going to be moving off this project at the end of this week so it may no longer be maintained after I leave. Teams within Palantir have been adopting IntelliJ recently. If you are hitting issues with this plugin, please consider other tooling options like IntelliJ, Sublime Text, Microsoft Code, etc.

[appcortez]

Am I getting it right this Palantir Eclipse TypeScript plugin will be stopped for any further developments..? BTW: thank you very much for your help Derek!

[derekcicerone-zz]

To be honest, I'm not sure - I'm handing off plugin development to some other folks within Palantir. I'm not sure how much time they will have to devote to this project but I'm guessing it will get less attention since this plugin hasn't been as popular as other tools for working with TS code.

[atsu85]

@derekcicerone, is there a good reason why You want to maintain Your own Eclipse plugin for TypeScript instead of trying to unite the forces with TypEcs? I see that both this plugin and TypEcs have really hard time on implementing new TypeScript features.

I've already created an issue to TypEcs repo to consider merging this plugin with palantir/eclipse-typescript, but it hasn't had any comments so far. @derekcicerone, @kosz78 what do You think about it?

There are certainly features that either of the plugins could take over from the other.

[appcortez]

In the meantime we played with closing all unrelated projects and this way the compile times are quite good: cca 1 sec if there are only 10-20 open projects in the workspace. Thanks God Eclipse can open all the referenced projects so we just have to open one web-app project...