[brundolf]

The key is to ignore 90% of TypeScript's features in the average application-level codebase. I avoid even using named generic types, much less conditional types etc.

Unfortunately, having all that power available is necessary because it has to be able to reasonably describe a highly-dynamic language. The more dynamic your JS is to begin with, the crazier your types will have to be to make sense of it. But most of that craziness can be avoided if you write straightforward logic with straightforward data structures to begin with.

[WorldMaker]

To expand on this, as someone with a deep sense of Typescript's features I start to flag them if I see them in PRs to applications. A lot of Typescript's features are for other people's code or for building blocks to smarter features (conditional types are interesting sure, but they sing in things like ReturnType<T>; you don't need to know the conditional type underpinnings to use the higher level ReturnType<T> feature).

I've had to break out some wild types to describe JS modules I've needed. If I need such things inside a TS application I control, I often see that as a failure to write clean/concise code in the domain language of the application itself rather than some "ideal" abstraction that may not matter (and I expect will eventually crumble into unreadable tech debt).

[brundolf]

> and I expect will eventually crumble into unreadable tech debt

Or crumble when tsc tries to follow them ;)

I’ve sometimes found, perhaps for the better, that when I get too creative with types the typescript compiler will at some point just not be able to follow what I’m trying to tell it any more. Even though my types are correct, theoretically, it will just sort of tip over. That usually serves as a good sign that I shouldn’t be trying to do what I’m doing at all.