WTF Typescript?! (The Standup)

TypeScript’s “WTF” moments mostly come from how it balances JavaScript’s duct-typed reality with compile-time safety—then draws sharp (sometimes surprising) lines. The standout example is excess property checking: passing an object literal with extra fields into a function that expects a narrower type triggers an error, but extracting the object first can make the error disappear. Even stranger, spreading an object can also “erase” the excess-property complaint, despite the extra fields still being present. The practical takeaway is that TypeScript’s structural typing isn’t always enforced the way developers expect, because the compiler treats inline object literals more strictly than values that flow in from elsewhere.

That same theme—type safety that depends on how values are introduced—shows up in enums. String enums behave differently from numeric enums: a function expecting a string enum rejects a raw matching string like “green,” while numeric enums accept corresponding numeric literals (and even reject out-of-range numbers). The discussion frames this as intentional compiler design rather than runtime behavior, but it still creates a day-to-day friction point: developers often end up importing enums just to pass values, even when they already “know” the literals.

To avoid enum runtime baggage and improve developer experience, many teams shift toward “const objects” plus type extraction. Instead of an enum, code defines a frozen-like object with `as const`, then derives a union type from its keys or values. This keeps the values visible for autocomplete, avoids importing a runtime enum object, and keeps the type aligned with the actual JavaScript values. The conversation also notes why enums can be a foot gun: numeric enums can have implicit ordering, so relying on auto-assigned numbers makes logic fragile if the enum order changes.

Beyond those headline quirks, the session stacks more compiler surprises that affect real codebases. A common one: filtering an array of `boolean`-guarded falsy values at runtime doesn’t always narrow the type the way developers expect, so TypeScript may still treat the result as `number | undefined` even when `undefined` can’t actually survive the filter. Workarounds include type guards, and the talk highlights a community library (TS Reset) aimed at “resetting” certain type-level inconsistencies back toward the mental model programmers expect.

The discussion also touches on type-level boundaries that trip people up: `{} ` (empty object type) is not equivalent to “only objects,” because it accepts many primitives (except `null`/`undefined`). And it goes further into the limits of what TypeScript can model—showing that the type system can be pushed into Turing-complete territory, and that type-level computation can produce concrete results (like arithmetic) purely at compile time.

Finally, the most consequential “WTF” is performance. At large scale—especially with monorepos, codegen, and heavy user-defined types—TypeScript can become painfully slow, with auto-suggest and builds taking seconds to minutes. Debugging that slowness is described as black-box work: flame graphs show where time goes, but not always why, and fixing it often requires deep knowledge of type evaluation, caching, and compiler internals. The session ends with a debate over whether some type-checking behavior should be stricter at call sites (especially around unions and mutability), but the broader message is consistent: TypeScript’s safety is real, yet its guarantees depend heavily on the shape of the code and the path values take through the type system.