50 TypeScript F*ck Ups (I’ve Made So You Don’t Have To)

TypeScript promises safety.
In practice, it gives you a false sense of it — until you learn how to actually use it.

Over the years, I’ve made every possible TypeScript mistake: from silent runtime bugs to type gymnastics gone wrong.

This is a survival guide — 50 TypeScript f*ck-ups, explained so you don’t repeat them.

Why TypeScript Feels Hard

TypeScript isn’t just “JavaScript with types.”
It’s a language layered on top of another language.

That means:

• It doesn’t change runtime behavior.

• It only changes how you think about code.

If you treat TypeScript like a stricter linter, it’ll fight you.
Treat it like a modeling tool, and suddenly, it starts working for you.

🧱 Section 1 — The Basics You Thought You Knew

1. Using any because “it’s faster”

any is TypeScript’s “whatever” button. It feels good until your types are meaningless.

function add(a: any, b: any) {
  return a + b;
}
add("5", 5); // "55" 🙃

✅ Takeaway: Use unknown or proper typing. any is just JavaScript with more steps.

2. Ignoring compiler warnings

If you’re seeing red squiggles, TypeScript is literally trying to save you.

✅ Takeaway: Treat warnings as bugs. Warnings today = production issues tomorrow.

3. Not enabling strict mode

Half the bugs in beginner TypeScript projects exist because someone forgot "strict": true.

✅ Takeaway: Add "strict": true to your tsconfig.json and never look back.

4. Confusing undefined and null

They’re not the same. undefined = not assigned. null = intentionally empty.
Mixing them makes your type guards cry.

✅ Takeaway: Pick one convention and stick to it. Prefer undefined in modern code.

5. Overusing ! (non-null assertion)

You’re basically saying, “Trust me, TypeScript, it’s there.” Spoiler: it’s not.

const name = maybeName!;
console.log(name.length); // 💥 runtime error

✅ Takeaway: Use type narrowing instead. Don’t silence your compiler like it’s your mom.

6. Forgetting nullish coalescing (??)

Stop using || when 0 or "" are valid values.

const count = input || 10; // breaks if input = 0
const fixed = input ?? 10; // ✅ correct

✅ Takeaway: Use ?? when you mean nullish, not falsy.

7. Using var in 2025

If you’re still using var, I hope you’re also using IE6.

✅ Takeaway: Use let or const. Scoping matters, and you’ll save yourself debugging pain.

8. Blind type assertions (as)

as is great until you start lying to the compiler.

const user = {} as User; // You just promised a lie.

✅ Takeaway: Assert only after validation, not imagination.

9. Forgetting about never

If a switch statement or function “can’t happen,” prove it.

function handle(x: "a" | "b") {
  switch (x) {
    case "a": break;
    case "b": break;
    default: const _exhaustive: never = x;
  }
}

✅ Takeaway: never makes your compiler your QA engineer.

10. Using object instead of proper types

object means “anything not primitive.” Not helpful.

✅ Takeaway: Define real shapes. Record<string, unknown> or an interface beats object every time.

🧩 Section 2 — Type System Pranks

11. Mixing up type and interface

They’re 90% similar — the other 10% breaks everything.

✅ Takeaway:

• Use interface for objects you’ll extend.

• Use type for unions, primitives, and utilities.

12. Over-engineering union types

type Result = Success | Failure | NetworkError | Timeout | Sadness
You’re writing a novella, not a type.

✅ Takeaway: Keep unions lean. Simplify before your brain melts.

13. Not using discriminated unions

If you’re checking for properties manually, you’re doing extra work.

type Response = { kind: "ok"; data: string } | { kind: "error"; msg: string };

function handle(res: Response) {
  if (res.kind === "ok") console.log(res.data);
}

✅ Takeaway: Use a kind field and let TS narrow for you.

14. Forgetting literal types

Why type status: string when you can do:

type Status = "loading" | "done" | "error";

✅ Takeaway: Be specific. string is too vague for real state machines.

15. Avoiding type guards

Type guards are how you make TypeScript smart.

function isUser(u: any): u is User {
  return u && typeof u.name === "string";
}

✅ Takeaway: Guard early, fail fast.

16. Not using keyof

If you find yourself typing property names twice, keyof exists for a reason.

✅ Takeaway: Automate key access — let TypeScript handle the strings.

17. Ignoring utility types

Why write this:

type PartialUser = { name?: string; age?: number };

When you can just do:

type PartialUser = Partial<User>;

✅ Takeaway: Partial, Pick, Omit, Record, and ReturnType are your best friends.

18. Overusing Pick

Sometimes you Pick so hard, you end up missing context.

✅ Takeaway: If you’re picking 5+ fields, maybe just define a new type.

19. Forgetting Readonly

Immutability is your friend. Especially with shared state.

✅ Takeaway: Mark what shouldn’t change. Save your future self from tears.

20. Nesting generics

When you’re at Promise<Array<Record<string, Map<string, User[]>>>>
…it’s time to stop.

✅ Takeaway: Break types into named pieces. Your eyes (and coworkers) will thank you.

⚙️ Section 3 — Generics Gone Wild

21. Weak generic constraints

function get<T>(arr: T[], index: number) { return arr[index]; }

✅ Takeaway: Add constraints! T extends object or T extends keyof U keeps your types honest.

22. Forgetting to infer generics

Don’t over-declare generics when TS can infer them.

✅ Takeaway: If TypeScript can figure it out — let it.

23. Using <T = any>

Defaulting to any defeats the purpose.

Get Ahmad Bilal’s stories in your inbox

Join Medium for free to get updates from this writer.

Subscribe

✅ Takeaway: Default to something meaningful, not chaos.

24. Generic shadowing

type Response<T> = { data: T };
function handle<T>(res: Response<T>) {} // same name, new headache

✅ Takeaway: Don’t reuse generic names inside functions. TS hates that.

25. Ignoring generic inference with functions

You can infer return types automatically. Stop over-specifying.

✅ Takeaway: Let TypeScript infer return types unless clarity demands otherwise.

🧭 Section 4 — Functions & Flow

26. Misusing optional parameters

Optional means “may be undefined,” not “don’t care.”

✅ Takeaway: Handle undefined before it handles you.

27. Using Function as a type

That’s like labeling your variable “thing”.

✅ Takeaway: Use (args: Args) => Return signatures. Always.

28. Forgetting overloads

Sometimes one function can have multiple signatures cleanly.

✅ Takeaway: Use overloads instead of union spaghetti.

29. Ignoring void

Return types matter. If you ignore void, you’ll chain undefined.

✅ Takeaway: Be explicit with void when functions only do, not return.

30. Misunderstanding async returns

An async function always returns a Promise. Always.

✅ Takeaway: Don’t double-wrap. Promise<Promise<T>> is a cry for help.

🧠 Section 5 — Classes & Objects

31. Uninitialized class properties

class User {
  name: string; // 💥 strict mode hates this
}

✅ Takeaway: Initialize or use definite assignment (!), but do it responsibly.

32. Using private where readonly fits

Not every field needs privacy; sometimes you just want immutability.

✅ Takeaway: Use readonly when it’s about protection, not secrecy.

33. Forgetting implements

Your classes are lying if they don’t implements the interface they pretend to follow.

✅ Takeaway: Explicit > implicit.

34. Overriding types in subclass

You “extend” the class but “break” the contract.

✅ Takeaway: Don’t weaken parent types — extend responsibly.

35. Async constructors

You can’t await new. Ever.

✅ Takeaway: Use a static create() method instead.

36. Missing this context

Arrow functions exist to fix your binding crimes.

✅ Takeaway: Prefer arrow functions in callbacks or event handlers.

37. Forgetting index signatures

If you’re storing dynamic keys, define them.

interface Dictionary {
  [key: string]: string;
}

✅ Takeaway: Index signatures are sanity savers.

38. Extending built-ins incorrectly

Extending Array or Error needs super() or things break mysteriously.

✅ Takeaway: When in doubt, call super().

⚡ Section 6 — Async & Edge Cases

39. Forgetting to await

Half of TypeScript bugs are just missing await.

✅ Takeaway: Await everything that’s async. You’re not saving time; you’re losing sanity.

40. Not catching async errors

Try/catch exists for a reason. So does .catch().

✅ Takeaway: Unhandled rejections are not “fine.”

41. Using enums for everything

Enums are overkill for static strings.

✅ Takeaway: Prefer as const objects — smaller, simpler, faster.

42. Mixing up unknown and any

unknown forces you to prove safety. any trusts you blindly.

✅ Takeaway: unknown > any when in doubt.

43. Skipping type narrowing

If you don’t narrow types, you’re just guessing.

✅ Takeaway: Use in, typeof, and instanceof — TS loves that.

44. Assuming async = parallel

await inside a loop is sequential. You wanted Promise.all().

✅ Takeaway: Await smartly, not blindly.

45. Ignoring readonly in arrays

const arr: readonly number[] = [1, 2, 3];
arr.push(4); // nope

✅ Takeaway: Use readonly arrays to prevent mutation bugs.

46. Async + forEach

forEach doesn’t await. It just runs and leaves.

✅ Takeaway: Use for...of with await, not forEach.

🧩 Section 7 — Design & DX

47. Missing type exports

You imported the type but forgot to export it. Welcome to refactor hell.

✅ Takeaway: Export your types deliberately.

48. Ignoring as const

It locks your literals and makes your types smarter.

const roles = ["admin", "user"] as const;
type Role = typeof roles[number];

✅ Takeaway: as const turns data into exact types.

49. Mixing runtime and type logic

TypeScript types disappear at runtime. Don’t expect them to save you in if.

✅ Takeaway: Types don’t exist after compile. Validate runtime inputs manually.

50. Forgetting it’s still JavaScript

TypeScript gives you types, not superpowers.
Bad logic with great types is still bad logic.

✅ Takeaway: TypeScript is a tool, not a babysitter.

✨ Closing Thoughts

You don’t learn TypeScript by reading the docs — you learn it by breaking things and fixing them.
I’ve done most of the breaking for you.

Use types as guardrails, not handcuffs.
Your future self (and your team) will thank you.