I created a TypeScript npm library with text processing utilities. Everything has proper type definitions so TypeScript users get compile-time safety. But I’m wondering if I should also include runtime validation like checking typeof value === 'string' in my functions. Can I just trust TypeScript types or do I need both compile-time and runtime checks? What happens when JavaScript users import my package without TypeScript? I want to make sure my library works reliably for everyone but I don’t want to add unnecessary code if TypeScript already handles this.
I’ve shipped several TypeScript libraries and learned this the hard way after production blew up. TypeScript’s types disappear at compile time, so any dynamic data or JavaScript users completely bypass your type safety. Even TypeScript users hit runtime issues with JSON parsing, API responses, or external data.
Be strategic about where you validate. Focus on entry points and functions that handle external input. I usually add simple type guards for primitives and basic structure checks for objects. This catches most misuse without bloating your bundle. Think of it as defensive programming, not redundant code.
totally agree! without runtime validation, things can go sideways, especially with js users. adding checks keeps stuff safe and prevents issues later. better safe than sorry, right?
Runtime validation is absolutely worth it for npm libraries, especially public ones. TypeScript types disappear when compiled, so JavaScript users get no protection from your type definitions. Found this out the hard way when my utility library started throwing weird errors for JS users passing unexpected data.
You don’t need extensive checks - just validate critical inputs that could crash things or cause weird behavior. Keep it lightweight by only checking the most important parameters instead of every property. Libraries like joi or zod work great if you want sophisticated validation without rolling your own. The small overhead is worth the reliability boost.