grunt-ts compile only the changed file

[eesdil]

trafficstars

There are two possibility to compile the only changed files:

• using external watch
• using internal watch

I have issue with both of them. With external watch the issue is that even though it knows the changed file, it compiles all of them.

With external watch the issue is that I cannot run with concurrent task as it is stopping the external watch (watching html, js files ...) The other issue is that when it runs it is taking 50% of my cpu.. (macbook air)

Let me know if you need more clarification.

thanks al ot

[nycdotnet]

Hi - thanks for the feedback. A significant limitation of grunt-ts (and any other tsc automation tool) is that it can't control how tsc itself works.

When compiling internal modules, grunt-ts doesn't know the interdependencies of the file to other TypeScript files; it relies on tsc to figure this out. Today, tsc doesn't have any sort of "fast" compile option, so unfortunately it has to compile all of the ones it is passed.

When compiling external modules - you're right: Grunt-ts doesn't allow further tasks to be run. It's intended as a "starter" watch functionality. If you are interested to run more steps in a watch pipeline I recommend looking into grunt-contrib-watch which grunt-ts can work with also. Then just don't use the grunt-ts watch functionality.

As far as the CPU utilization is concerned - again that's all tsc and Node.js. You may wish to look into using TypeScript 1.3 which is up to 4x faster than 1.0 or earlier. It may still use up a lot of CPU, but at least it will be for less overall time and hopefully less noticeable.

Let me know if this doesn't make sense or if I've answered the wrong question.

[eesdil]

Hi, thank you for taking the time to answer.

I understand this limitation, this part is fine. But.

I was trying to run grunt-ts without the watch function and using contrib-watch. But this time even tough the contrib-watch (and therefore grunt-ts) knows the changed file, it is still compiling everything. I believe if it knows the file it can pass just one file instead of all of them.

Regarding the utilisation. Also I understand that it is not about grunt-ts, but if I use the normal watch I have around 10% used of my cpu. However if I run grunt-ts as watch it is using 50%. which is significant difference. And here I don't speak about the effective compilation, but just the waiting stage.

I will come back just to reconfirm that this is the case as now I am using different setup with grunt-ts.

btw, thanks a lot for maintaining this tool. Still it is very useful.

[nycdotnet]

Here's the problem I see with sending one file:

a.ts

class MyClass {
    public myProperty = "";
}

b.ts

///<reference path="a.ts" />
var x = new MyClass();
x.myProperty = "new value";

What happens if I change the property on MyClass to be called myOtherProperty and save it? If I just compiled a.ts, then b.ts would be wrong, but you wouldn't get any errors back from TypeScript.

Are you OK with that?

[eesdil]

The problem is that compiling all the files take minimum 3 seconds and on a slower machine (or virtual) 7-8 secs. To wait every time this time is not really convenient, even though it is correct. I think Visual Studio does this, just compiles one file when it saves it and does not care about the other files. To have a continues workflow this is necessary.

Would be great if we could have a file which is having the relations between the files. In the example , we could see that a and b are related and if a changes b should be compiled also, but nothing else... Also having this without defining the references for every file, that would be great.

But now I am not using grunt-ts to compile the files separately. I have the tsc command in the editor to compile the file after it is saved. I need this to get back the errors in the editor itself where I can jump to lines in case of errors. I am using grunt-ts for creating and maintaining the reference file and also create the initial js file during grunt start.

So if I could use grunt-ts to compile and get back errors in the editor itself like this, I would immediately use it as compiling after save.

[basarat]

If you are interested to run more steps in a watch pipeline I recommend looking into grunt-contrib-watch which grunt-ts can work with also.

:+1:

But this time even tough the contrib-watch (and therefore grunt-ts) knows the changed file, it is still compiling everything

Make sure you have watch option set to always.

However if I run grunt-ts as watch it is using 50%. which is significant difference. And here I don't speak about the effective compilation, but just the waiting stage.

we've heard this before. MacOSX? Nevertheless issue with chokidar. This is the one karma uses. The one grunt-contrib-watch uses has similar issues with random file structures on random operating OSes.

---

moreover

Fast compile

What happens if I change the property on MyClass to be called myOtherProperty and save it?

Just FYI same issue will happen with external modules

a.ts

class MyClass {
    public myProperty = "";
}
export = MyClass;

b.ts

import MyClass = require('./a.ts'); 
var x = new MyClass();
x.myProperty = "new value";

What happens if I change the property on MyClass to be called myOtherProperty and save it? If I just compiled a.ts, then b.ts would be wrong, but you wouldn't get any errors back from TypeScript.

Will still happen. This was a conscious choice. If we follow the dependency arrow up and then down again then we would end up compiling Everything which would defeat the purpose of fast compile. After all you should not have a file in your project that is unreachable from any other top level code ;)

Would be great if we could have a file which is having the relations between the files. In the example , we could see that a and b are related and if a changes b should be compiled also, but nothing else... Also having this without defining the references for every file, that would be great.

See the mentioned reason.

[nycdotnet]

@basarat Did we ever reach out to the Chokidar folks? They seem pretty responsive and are putting out new releases very frequently. I wonder if we could get a minimalist repro going.

@eesdil Would you perhaps want to try updating your Chokidar to see if it helps with the CPU utilization problem? Edit your ./node_modules/grunt-ts/package.json and update the chokidar version to "0.12.5" under the dependencies section. Then run npm update chokidar from that same folder. Let us know if the CPU utilization while watching is any better. Thank you.

[basarat]

Did we ever reach out to the Chokidar folks

Actually the issue was with gaze : the one that grunt-contrib-watch uses. So we changed ship and that fixed it for us. I've had colleague who had sporadic issues with karma on mac so know that chokidar can be dodgy too. Haven't had a reliable reproduction though.

Edit your ./node_modules/grunt-ts/package.json and update the chokidar version to "0.12.5" under the dependencies section. Then run npm update chokidar from that same folder. Let us know if the CPU utilization while watching is any better. Thank you

:+1:

[eesdil]

So after using "0.12.5" it went from 90% to 0.2% cpu...

[nycdotnet]

Well that's better...

[nycdotnet]

@basarat Now that you're more familiar with the TypeScript language services, do you think a good goal would be to implement the watch functionality that way and deprecate the current "fast" functionality?

@eesdil Is your issue resolved when using TypeScript 1.1 or higher with the updated Chokidar?

[eesdil]

yes, sure, with the Chokidar update it is fine. Thank you.

[nycdotnet]

Excellent - thanks for the report.

[basarat]

Now that you're more familiar with the TypeScript language services, do you think a good goal would be to implement the watch functionality that way and deprecate the current "fast" functionality

No. Various reasons:

• Sadly grunt-ts is designed to work well with grunt-contrib-watch. This means that we get Loaded and unLoaded from memory based on how grunt-contrib-watch calls us. Language service speed ups are only awesome if we keep it in memory.
• Supporting multiple compiler versions with conflicting language service api will be difficult. We support many compilers because of simply executing tsc on the command line (much more stable).

Grunt-ts is awesome for a build server :heart: