Use ts-node with TypeScript incremental build

[AlexZeitler]

Is it possible to use ts-node with TypeScript 3.4+ incremental build options?

[blakeembrey]

Discussed in #811. It'd be nice but isn't possible at this time because the API doesn't exist.

[AlexZeitler]

Thanks

[G-Rath]

microsoft/TypeScript#29978 tracks the exposure of the API by TS, which is currently targeted at 3.5.x

If ts-node has any plans to support the feature then that's the issue to watch. Depending on how you guys run your repo, you might want to re-open this issue for tracking, since it's definitely on the TS teams rader as something they want to ship ASAP.

Either way, wanted to put this here for visibility, since #811 is about removing the properties :)

[Chris911]

The referenced TS issue has been merged! Not sure when it'll be released but it's still tagged as a 3.5.x candidate.

[G-Rath]

@Chris911 The email for your comment somehow arrived before the email about the PR being merged & closed 😂

iirc on the roadmap it's been kicked back to 3.6.x, but either way we can expect it "soon" - pretty sure now that it's merged implementation could already begin, by just installing master; otherwise, we actually only need an RC release :D

[Toub]

Should be soon... Typescript 3.6 final is planned for... yesterday :-)

microsoft/TypeScript#31639

[Toub]

Here we are :-) https://devblogs.microsoft.com/typescript/announcing-typescript-3-6/

[sajadghawami]

Does ts-node automatically pass the --incremental flag?
In other words, Is this ready for usage now? :)

[vmarchaud]

@sajadghawami I believe it doesn't, ts-node need to use the implement the new API released in 3.6

[insidewhy]

I'm working on an incremental cache for ts-node here: https://github.com/ohjames/ts-node/tree/jpike/cache

It doesn't need to use the incremental API though.

There's also an option to include js files in the cache for this implementation.

Why cache included js files? Because docker mac filesystem access is incredibly slow. So so damn slow. So in our case we are using a tmpfs mount inside of our containers. By caching everything inside of tmpfs we can avoid having to access the filesystem the second time the project is run. This means that when we restart our code via nodemon, instead of having to wait 40 seconds for our server to start up, we now only have to wait 1 second.

[blakeembrey]

@ohjames that looks unrelated to this issue, please keep it separate. This issue is specifically around using the incremental compilation API available in TypeScript. The solution you’ve written is actually available on an older version of this package and it would be preferable to just re-use that functionality - the reason it was removed is because you end up having transitive type issues on changed code.

Edit: Actually, it’s possible I misread the code on my phone too. Are you saying it’s a cache for source files? In any case, I’d prefer to have this discussion in a new issue.

[tangentlin]

Hi, I wonder if there is any updates with this issue? Supporting incremental build from TypeScript 3.6 API would be hugely beneficial in performance. Thanks!

[blakeembrey]

@tangentlin It's supported on master but is not available for release. The TypeScript build cache hasn't had any measurable effect that I can see so I'm probably using the API incorrectly in some way. However, the master build can not be released because it does not support project references properly (as in backward compatible with how it worked before, it appears to work differently to tsc --build so requires more work).

[blakeembrey]

Anyone reading this or other issues is welcome to pitch in and open a PR, right now I just don't have the personal bandwidth to figure it all out.

[realyze]

Is this PR related to this issue please: #895 It adds incremental option. Should this issue be closed or am I misunderstanding? I should've read the message above, sorry. :)

[blakeembrey]

You’re correct, it is available for people! Please test it. But unfortunately it doesn’t cover the references use-case yet, which means it’s not on by default. It’s possible to workaround with new options like registering multiple scoped compiler instances, but it’d be nice for it to work like the typescript compiler before we release it as default.

[pbn4]

How do I turn this on? setting 'incremental' in tsconfig.json does not seem to work for me.

[ProTip]

@pbn4 It appears both TS_NODE_COMPILER_HOST and TS_NODE_EMIT need to be true as well. I can get it to emit the tsconfig.tsbuildinfo file, but there is no speedup between runs for me. It seems the compiler may not be using that information when it runs.

[bradharms]

@pbn4 It appears both TS_NODE_COMPILER_HOST and TS_NODE_EMIT need to be true as well. I can get it to emit the tsconfig.tsbuildinfo file, but there is no speedup between runs for me. It seems the compiler may not be using that information when it runs.

In my case it seems the build time actually doubles when I try to use these options.

[bradennapier]

Is fixing this dead now? Just switched to incremental and now all my ts-node is broken :(

[cerinoligutom]

Any updates on this?

[saltire]

The TypeScript 4.4 beta announcement has this to say:

Faster Incremental Builds with --strict

In what was effectively a bug, TypeScript would end up redoing type-checking work under --incremental compilations if --strict was on. This led to many builds being just as slow as if --incremental was turned off. TypeScript 4.4 fixes this, though the change has also been back-ported to TypeScript 4.3.

See more here.

Not sure if this is related, but for folks who weren't seeing a speedup with --incremental, maybe it's worth trying again once the fix is released?

[bmaupin]

Using ts-node 10.4.0 with TypeScript 4.5.5, I see no noticeable speed difference with "incremental": true in tsconfig.json (assuming that's how to use it with ts-node).

[programORdie2]

Any updates on this?