TypeScript Patterns for Environment Variables

Yesterday, as I was working on a CORS configuration, AI generated a block of code for me: const allowedOrigins = [ process . env . FRONTEND_URL || " http://localhost:3000 " , process . env . ADMIN_URL || " http://localhost:3001 " , ]. filter ( Boolean ); I was wondering... why use .filter(Boolean) here? 🤔 The fallbacks already guarantee strings. So I hovered on the variable. The type definition read: const allowedOrigins : string [] Fine. Made sense. But then I got curious. What if I removed the hardcoded fallbacks? const allowedOrigins = [ process . env . FRONTEND_URL , process . env . ADMIN_URL , ]. filter ( Boolean ); My type definition changed to: const allowedOrigins : ( string | undefined )[] I was shocked. I just filtered the array. How can TypeScript still think there's an undefined in there? First: What Does .filter(Boolean) Even Do? Boolean used as a filter function removes any falsy value from an array: false null undefined 0 "" NaN So: [ " https://app.com " , "" , undefined ]. filter ( Boolean ) // Result: ["https://app.com"] At runtime, this works exactly as you'd expect. No undefined survives. So why does TypeScript disagree? 🤷‍♀️ The Real Answer: TypeScript Doesn't Run Your Code TypeScript is a transpiler. It doesn't execute .filter(Boolean) — it only looks at types. When it sees this: array . filter ( Boolean ) It knows the callback returns a boolean . But it doesn't know what that means for the type of the elements that survive. It can't infer "if Boolean(x) is true, then x must be a string." So the undefined stays in the type — even though it'll never actually be there at runtime. That's the gap: your runtime behavior is correct, but your types are lying. The Fix: Type Predicates TypeScript lets you close that gap with a type predicate — a way of explicitly telling the compiler what a filter function guarantees: const allowedOrigins = [ process . env . FRONTEND_URL , process . env . ADMIN_URL , ]. filter (( origin ): origin is string => Boolean ( o