Handling `unknown` in TypeScript… isn't it painful?

try { if(localStorage) { let currentUser = localStorage.getItem('current_user'); if (currentUser) { currentUser = JSON.parse(currentUser); if (currentUser.id === 1436158) { document.getElementById('article-show-container').classList.add('current-user-is-article-author'); } } } } catch (e) { console.error(e); } nyaomaru Posted on Apr 28 Handling `unknown` in TypeScript… isn't it painful? #webdev #programming #opensource #typescript Hi there 👋 I'm a frontend engineer based in the Netherlands, currently suffering from hay fever 😿 API responses, form inputs, external data… In TypeScript, we often end up dealing with unknown, and handling it properly can become a real pain in day-to-day work. Yes, unknown has a kind of gravitational pull like the universe. But still… we do want to handle types safely, right? That’s where is-kit comes in a library for composing type guards. nyaomaru / is-kit Lightweight, zero-dependency toolkit for building `isFoo` style type guards in TypeScript. Runtime-safe 🛡️, composable 🧩, and ergonomic ✨. npm -> https://www.npmjs.com/package/is-kit is-kit is-kit is a lightweight, zero-dependency toolkit for building reusable TypeScript type guards. It helps you write small isFoo functions, compose them into richer runtime checks, and keep TypeScript narrowing natural inside regular control flow. Runtime-safe 🛡️, composable 🧩, and ergonomic ✨ without asking you to adopt a heavy schema workflow. Build and reuse typed guards Compose guards with and, or, not, oneOf Validate object shapes and collections Parse or assert unknown values without a large schema framework 📚 Documentation Site Best for app-internal narrowing, filtering, and reusable guards. 🤔 Why use is-kit? Tired of rewriting the same isFoo checks again and again? is-kit is a good fit when you want to: write reusable isX functions instead of one-off inline checks keep runtime validation lightweight and dependency-free narrow values directly in if, filter, and other TypeScript control flow compose validation logic… View on GitHub Libraries like Zod take a schema-first approach. In contrast, is-kit focuses on narrowing types within your existing code. Instead of “writing validation”, you can think of it as extending your everyday if statements with type safety. If Zod is for boundaries (API / input) is-kit is for inside your application logic A simple example Imagine you need to check “strings with length ≤ 3” multiple times. With is-kit, you can define it once and reuse it: import { define, isString } from "is-kit"; const isShortString = define<string>( (value) => isString(value) && value.length <= 3, ); Enter fullscreen mode Exit fullscreen mode Then use it like this: import { isShortString } from "~/utils/is"; declare const input: unknown; // before → repeating conditions every time if (typeof input === "string" && input.length <= 3) { input.toUpperCase(); } // after → reusable guard if (isShortString(input)) { input.toUpperCase(); } Enter fullscreen mode Exit fullscreen mode This style works seamlessly with if, filter, map, and other existing logic. 🐾 How is-kit has evolved It’s been about 6 months since the v1.0 release. Back then, is-kit started as a lightweight type guard library with primitives like: define and or struct arrayOf Since then, up to v1.6, it has gradually evolved into something more practical: 👉 a toolkit for handling unknown values in real-world applications Let’s look at 5 major improvements. 🪄 1. Distinguishing “missing” vs…

This excerpt is published under fair use for community discussion. Read the full article at DEV Community.