Compiler Errors

A diagnostic is a compiler message about your program. Read it in three parts: location, error code, and explanation. TS2322 identifies an assignment mismatch. The line and column point to where the checker detected the conflict, which may be where a value is used rather than where it originated.

Use a small debugging loop: check the program, read the first message, describe what type was expected and what arrived, fix the cause, then check again. One wrong declaration can cause several later messages. Fixing the first cause can remove the rest.

Type errors and runtime errors happen at different stages. A missing property can be caught before execution when the object type is known. A throw statement runs only when execution reaches it. A logic mistake, such as adding when you meant multiplying, can use perfectly valid types and still give the wrong answer. That is why predictions and tests matter.

Our playground intentionally refuses to run a program with compiler errors. Elsewhere, build tools can sometimes emit JavaScript despite errors or strip types without checking them. Do not assume seeing output means a real type check happened.

Avoid using any to silence a message. It turns off useful checking for that value and can spread through the program. A suppression comment asks the checker to ignore a problem; a type assertion asks it to trust a type you supply without checking the data. You do not need either syntax here; Day 6 explains assertions when comparing them with real validation. First ask whether the data, the annotation, or the operation is wrong.

Predict, check, then run

Before running, write down the output and explain which information the checker knows. Click Check types first, then Check & run.

const sessions = 3;
const minutesPerSession = 20;
const incorrectTotal = sessions + minutesPerSession;

console.log(incorrectTotal);
console.log(sessions * minutesPerSession);

23
60

Read a real compiler error

The value has the wrong capabilities for this operation. Read which type owns the missing property.

const minutes = 25;

console.log(minutes.toUpperCase());

Separate type mistakes from wrong calculations

The compiler checks relationships between types, not the meaning of your arithmetic. Two valid numbers can still be combined with the wrong operator or the wrong units. A clean check therefore means the program is eligible to run, not that its answer is correct.

Use a small expected result you can calculate independently. When an error message mentions an assignment or argument, repair that specific relationship first. Then execute a meaningful example; changing types merely to silence a diagnostic can preserve the original behavior bug.

const hours: number = 2;
const minutesPerHour: number = 60;

console.log(hours + minutesPerHour);
console.log(hours * minutesPerHour);

62
120

Both expressions compile. Only multiplication implements the intended conversion from hours to minutes. The expected 120 comes from the problem, not from the checker.

const entered: string = "20";
const converted: number = Number(entered);

console.log(converted + 5);
console.log(entered + 5);

25
205

The annotations document the distinction but do not perform conversion. Number is the runtime operation that creates a numeric value. The original input remains text.

Try the rule on new inputs

Introduce one actual type error and one valid-but-wrong calculation. Predict which Check types catches. For the calculation, choose a concrete expected answer and explain why a runtime test is still necessary.

Your turn

const sessions = 3;
const minutesPerSession = 20;
// Calculate totalMinutes and print it.

const sessions = 3;
const minutesPerSession = 20;
const totalMinutes = sessions * minutesPerSession;

console.log(totalMinutes);

60

Change it and explain it

Change both inputs to zero and predict the output. Then deliberately misspell minutesPerSession and read the compiler message. Restore the spelling. Write one example of a defect types catch and one they do not.