Hacker News Reader

Comment by corrral | Hacker News Reader

It reads more like a case for caching, or for a much more capable bundler (that can include an "I am version XXXX and already checked this, it's good" note in the bundle). Certainly, it seems like it would have been safer to leave the default alone and add a "do-not-typecheck" flag.

View on HN

The unfortunate thing about TypeScript is that incremental type checks are still very slow, because any file can influence the type of any other file, without the other file knowing. It's a design issue, that is unfortunately very unlikely to be fixed at this point.

Also, we already have a "do-not-typecheck" flag (`--no-check`), we were just seeing in real world usage that nearly everyone who uses Deno professionally would enable this flag for inner loop development, and leave type checking up to CI and their IDE. If 95% of your users use a flag that changes a default, then that changed value should probably be the default (resulting in a better experience for most people) :)

> The unfortunate thing about TypeScript is that incremental type checks are still very slow, because any file can influence the type of any other file, without the other file knowing. It's a design issue, that is unfortunately very unlikely to be fixed at this point.

That makes sense, thanks.

> Also, we already have a "do-not-typecheck" flag (`--no-check`), we were just seeing in real world usage that nearly everyone who uses Deno professionally would enable this flag for inner loop development, and leave type checking up to CI and their IDE. If 95% of your users use a flag that changes a default, then that changed value should probably be the default (resulting in a better experience for most people) :)

I'm still not a big fan of changing defaults for commands that may e.g. be part of scripts, outside major version jumps, but I get the motivation if the no-check flag was in fact far more oft-used than the default behavior.

At Brex we tried to speed up the typecheck speed in CI by saving and reusing the build output from the incremental cache.

It worked pretty well for the most part, and I would recommend looking into this for most teams since it's a pretty quick win. Most typecheck steps went from minutes to low-double-digit seconds (admittedly still slower than I would have hoped).

But occasionally there would be gigantic spikes back to minutes for seemingly small changes that seem like they should have been incrementally check-able. I suspect these might have something to do with circular dependency chains, but didn't have bandwidth to dig deeper.

I wish TypeScript's incremental checking mechanism and file formats was a bit better documented and less opaque, so people could better reason about and optimize typechecking performance, and possibly build support into other systems to perform & share some of the analysis they're already doing to avoid wasted work. That and to make it less of a giant blob for the entire codebase, and more of a set of files that are incrementally and individually update-able for better cache granularity and faster updates.

Deno already automatically performs incremental type checking with a cache whenever possible. In most cases this is still _very_ slow though (double digit seconds).

Reply on news.ycombinator.com