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).
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.
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.