Read errors like a local
Most of a TypeScript workday is a loop: write, compile, read an error, fix. Decoding the error text quickly is therefore a core skill in its own right — the difference between a ten-second fix and an hour of guessing. TypeScript errors follow patterns. Learn six and you can decode almost everything:
| Error | Real meaning |
|---|---|
Type 'X' is not assignable to type 'Y' | value of the wrong type, check the annotation |
Property 'p' does not exist on type 'T' | typo, or you must narrow the union first |
Argument of type 'X' is not assignable to parameter... | wrong argument at a call site |
Expected 2 arguments, but got 1 | missing argument, check optional ? |
Parameter 'x' implicitly has an 'any' type | annotate the parameter, strict mode |
'x' is possibly 'null' or 'undefined' | add a null check before use |
The habit that matters: read the error bottom to top and inside out. The last line usually names the exact property that mismatched, and the reported file and line point at the true location.
Quiz
You see: Property 'toUpperCase' does not exist on type 'string | number'. What is the compiler really telling you?
Problem
A teammate hits: Parameter 'user' implicitly has an 'any' type. Which single compiler option (one word, the flag name) is demanding the annotation?
Code exercise · typescript
Debug finale. This program has two type errors: a misspelled property read and a string where a number belongs. Run it to read both compiler messages, fix them, and make it print the expected output.
Code exercise · typescript
One more from the table. This program fails to compile with 'email' is possibly 'null' — and the compiler is right, findEmail can return null. Fix the final lines by narrowing: print the uppercased email when it exists, or "no email" otherwise, so the program prints the expected output.
Where to go next
You now hold the working core of TypeScript: annotations and inference (Unit 1), the core types (Unit 2), interfaces (Unit 3), unions and narrowing (Unit 4), typed functions (Unit 5), generics (Unit 6), utility types and boundary checking (Unit 7), and project configuration (Unit 8).
Everything else in the language, mapped types, conditional types, decorators, is built from these pieces, and you can learn each one when a real codebase puts it in front of you. The best next step is to use TypeScript by default: your practice projects, your DSA solutions in the editor, and any React or Node work ahead. Strict mode on, any off, and let the compiler carry the details.
Quiz
Final check. Which statement about TypeScript is FALSE?