Functional programming with TypeScript: what fp-ts teaches you even if you never ship it
The correct solution for handling nullables in TypeScript is to add more types. I know that sounds like bureaucracy. But it was exactly the idea behind fp-ts's Option<T> that made me realize every undefined I was returning without context was a broken contract waiting to blow up at runtime — I've seen that exact blow-up in a Next.js action, where an empty undefined came back from a query and three components down the tree just assumed it would always be there.
I never installed fp-ts in production. Didn't need to. But reading its source changed how I think about data flows in strict TypeScript — in Server Actions, in Zod schemas, in any function that deserves an honest signature.
My thesis, and I'll stand behind it: fp-ts is a university, not a framework most teams should deploy. Treat it as a way to sharpen how you think about contracts, not as a dependency you add on day one. Ignoring it completely, though, means leaving some of the most useful reasoning patterns for strict TypeScript day-to-day work sitting right there on the table.
Why fp-ts makes real-world TypeScript developers uncomfortable
