Typically, TypeScript type-checks `lib.d.ts` every single compilation which can add at least half a second of build time. It will also do a full check of `.d.ts` files in your dependencies, which can also be pretty heavy.

We're considering ways we can avoid a full type check: https://github.com/microsoft/TypeScript/issues/31417

In the meantime, you can try out turning on the `skipLibCheck` compiler option to see if that helps at all, but be warned that it might not catch conflicts across multiple files.

Is the check of `lib.d.ts` not helped by --incremental?

Very specifically, 3.4 had a few perf regressions for some type signatures [1]. More generally, TS can be a bit slow (~seconds) especially for large webapp development if you need hot-reloading and such. There are tricks to emit without checking and doing async checking during the dev process which speeds things up quite a bit.

[1] https://github.com/Microsoft/TypeScript/issues/30663

I'm using 3.5.1, the issue is I don't have very many files and it's in a Node environment where it transpiles the file to the output directory with no bundling or hot reloading included.

What are some of these tricks to skip checking or do async checking? I did a quick search and came up with a GitHub issue [0] for adding the option to skip checking, but didn't see anything myself.

[0] https://github.com/Microsoft/TypeScript/issues/29651

Theres tooling for this for webpack described: https://github.com/TypeStrong/ts-loader#faster-builds

More generally though you have two loops one that does transpileOnly and one that doesn't. The latter is your type check process.

As I said there's no bundling, such as webpack.

Yes, the Typescript compiler is slow.

I tend to notice all compilers as feeling "too slow". I think the cause is that we all have wayyyy too much code. Not that we write, but when we use a library, that uses 10 libraries, that each use 10 libraries. Now you have a million lines of code, and all you wanted to do was print hello world. The compiler doesn't know until it's read all of that that you aren't using any of it. The solution is to depend on libraries more carefully.

As the go team says, a little copying is better than a little dependency. This is a motto that the npm community has NOT taken to heart. The cost is slow build times. (To be fair, the go community has not taken this to heart either.)

We do at Asana. I have not worked on it recently but I do believe that certain type signatures can have a large impact on build times.

TS 3.4 has known performance regressions. 3.5 helps, but it's still slower than 3.3.

I don't really notice it, though, because I've got `tsc --watch` running in a terminal continuously as I edit code.

When tsc sees edits, recompilation competes in tens of ms. It's really quick.

Have you ruled out node and disk access time? If 30-file builds are taking 3s I suspect a sizable chunk of that is overhead (i.e. I'd expect the same from node-sass on 30 .scss files).

Nope, strace reports 0.03s for all calls and about 0.02s of that is for filesystem stuff.