While I certainly agree, I've found that this is often an indication of too-complex an architecture, and a fundamental re-think being necessary. I've had projects that depend on [fp-ts], which end up incredibly generic-heavy, but still make it entirely through a typecheck(not build- typescript's just worse at that than other tools like esbuild) in seconds-at-worse.
Obviously depends on your organization/project/application, but I do like these things as complexity-smells.
How large in lines of typescript are the projects you've used fp-ts or similar with?
We have about 3 million; when I discuss a slow type, i mean a type that contributes ~1 min of checking or more across all the uses in 3 million lines, analyzed from a build profile using Perfetto. I've looked at a generic-heavy library that's similar (?) to fp-ts, effect-ts (https://effect.website/), but I worry that the overhead - both at compile time with the complex types, and at runtime with the highly abstracted control flow that v8 doesn't seem to like - would be a large net negative for our codebase.
Nothing that large admittedly- but I have gotten near the 1 million mark(prolly ~800k?) in one project. But I'd also say that at that size(honestly these days, I reach for it pretty much by default) I'd go toward a monorepo that only runs CI on the packages that have changes, as that much JS to even just go through a typical eslint is gonna be a real chore. As a result, the 'complex types' don't end up impacting as much.
As to runtime: While v8 doesn't like it, what it doesn't like even more is having code to run in the first place- and I've found that my FP-heavy projects often have fewer lines of code by factors of 3 at worse, often as high as 15. So in general I didn't get much in the way of perf issues, and when there would be a place that perf mattered, I'd then rewrite it to not use the FP stuff and instead be written to purpose.
Basically, I use FP(and by extension fp-ts) as a good default(as it increased velocity by enormous factors, and more as time went on), then reach for the toolbox when the situation called for it.
BIG ASTERISK however: I don't use `fp-ts` much in React however. With it primarily depending on `Object.is` for comparison, the pure nature of the libraries creates a need for a lot of tools I wasn't able to find a satisfactory answer to. So most code like this was either accomplishing things outside of components(components would often call them though), or was backend-focused(ie, Node.js).
Obviously depends on your organization/project/application, but I do like these things as complexity-smells.
[fp-ts]: https://gcanti.github.io/fp-ts/