[jitl]

Word of warning: the typescript compiler is not a particularly fast evaluator of recursive list manipulation programs, which is what these kinds of types are.

They’re great in small doses where you really need them, but overuse or widespread use of complex types will make your build slower. It’s much better to avoid generics or mapped types if you can. The typings for a tagged template literal (without digit format specifiers like %d4) don’t require any generics.

I love to write code like this, but I’m guilty of over using fancy types and I flinch when I see a typescript build profile showing 45s+ spent on generic types I wrote without realizing the cost.

[kevingadd]

The nature of ts also means that if you make your files slower to build via type/list nonsense, the language server is going to bog down and the editing experience will mysteriously become bad for everyone. Strongly discourage doing slow stuff with the type system.

[quaunaut]

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.

[fp-ts]: https://gcanti.github.io/fp-ts/

[jitl]

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.

[quaunaut]

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