Strict mode options

One setting, many checks

A shop page looks up a product's price by name. The code below has three problems. With strict checks on, which is how this page checks every example unless it says otherwise, TypeScript marks all three, on purpose here:

1type Product = { name: string; price: number };2const products: Product[] = [{ name: "Tea", price: 3 }];3 4function priceOf(name) {5  const product = products.find((item) => item.name === name);6  return product.price;7}8 9try {10  console.log(priceOf("Cake"));11} catch (error) {12  console.log(error.message);13}

Line 1 says what a Product is, and line 2 makes a list with only tea in it. Line 4 starts priceOf, line 5 looks for the product with find, and line 6 returns its price. Line 10 asks for cake, which isn't there, so line 6 throws a TypeError. The catch block on lines 11 and 12 catches it (the try...catch lesson covers this) and prints Cannot read properties of undefined (reading 'price'). The three marks:

• Line 4, Parameter 'name' implicitly has an 'any' type: nothing says what name holds.
• Line 6, 'product' is possibly 'undefined': find gives back undefined when nothing matches. This is the crash.
• Line 12, 'error' is of type 'unknown': code can throw anything, not only errors, so TypeScript won't let you read message before you check.

In Setting up a project you turned on "strict": true and saw it catch the first two. What you didn't see is that strict isn't one check. Each of these three errors comes from a different check, and each check has its own name, called a flag: a setting in compilerOptions that is true or false. strict is a shortcut that turns on nine of them. Other flags aren't in the group, and a project adds them by name:

1{2  "compilerOptions": {3    "strict": true,4    "noUncheckedIndexedAccess": true,5    "exactOptionalPropertyTypes": true,6    "noImplicitOverride": true7  }8}

Line 3 turns on the strict group. Lines 4 to 6 add three checks from outside it, which this lesson covers one by one. In TypeScript 5.9, every flag here is false unless something turns it on. (TypeScript 6.0 and later turn strict on by default, as Setting up a project mentioned, but writing it keeps every version the same.)

What strict turns on

Here is the price lookup again. The code never changes; only the settings do. Turn on one check at a time and watch which line each one marks:

1type Product = { name: string; price: number };2const products: Product[] = [{ name: "Tea", price: 3 }];3 4function priceOf(name) {5  const product = products.find((item) => item.name === name);6  return product.price;7}8 9try {10  console.log(priceOf("Cake"));11} catch (error) {12  console.log(error.message);13}

{
  "compilerOptions": {
    "strict": false
  }
}

Start with strict: false: no errors, even though the code crashes. Each of the next three buttons turns on one flag and gets exactly one error. strict: true gets all three. Notice that line 12's message changes. With only useUnknownInCatchVariables on, it's Property 'message' does not exist on type 'unknown'; with strictNullChecks on as well, TypeScript says it more directly. The last button keeps strict on and turns one flag off. The order in the file doesn't matter: a flag you name always wins over the group.

That last button is how a project keeps strict on while it isn't ready for one or two checks yet:

1{2  "compilerOptions": {3    "strict": true,4    "strictNullChecks": false,5    "strictPropertyInitialization": false6  }7}

Line 3 turns on the whole group. Lines 4 and 5 turn two of its checks off again. Everything else in the group stays on, and any check a future TypeScript adds to strict turns on too. The TypeScript documentation says this plainly: a new version may add stricter checks under strict, so an upgrade can bring new errors.

In TypeScript 5.9 the group has nine flags. Read each row of the table as: this flag, what it reports, and where this lesson shows it. You've met the first two before, in any, unknown & never and null and undefined.

Four quieter checks inside strict

noImplicitAny and strictNullChecks find the most errors. Four others find fewer, but each one catches a real kind of bug. Each example below is checked with strict on, and each has one error on purpose. First, a class field that never gets a value:

1class CartBadge {2  count: number;3  label = "Cart";4}5 6const badge = new CartBadge();7console.log(`${badge.label}: ${badge.count}`);

Line 2 says every CartBadge has a count that is a number, but nothing ever gives it one. Line 3 is fine, because label starts as "Cart". strictPropertyInitialization marks line 2: Property 'count' has no initializer and is not definitely assigned in the constructor, which means "no starting value, and the constructor doesn't set one either". Line 7 prints Cart: undefined. (Classes in TypeScript covers fields.)

1type ClickHandler = (event: Event) => void;2 3function logPosition(event: MouseEvent) {4  console.log(event.clientX);5}6 7const handler: ClickHandler = logPosition;

Line 1 describes a handler that may be given any Event, like a key press. Line 3's logPosition only works with a MouseEvent, because line 4 reads clientX, the pointer's position. Line 7 tries to store it as a ClickHandler. strictFunctionTypes marks it: Type '(event: MouseEvent) => void' is not assignable to type 'ClickHandler'. Called with a key press, line 4 would print undefined. The next lines of the message list the missing properties.

1function applyDiscount(total: number, percent: number) {2  return total - (total * percent) / 100;3}4 5console.log(applyDiscount.call(null, 20));

Every function has a call method whose first argument is the value for this and whose others go to the function (Methods and this covers it). Line 5 passes only one of the two numbers. strictBindCallApply checks those arguments like a normal call, so it says Expected 3 arguments, but got 2: the this value plus two numbers. Without it, line 5 would quietly print NaN, as it does when you run it.

1const badge = {2  label: "Cart",3  show: showLabel,4};5 6function showLabel() {7  return `Label: ${this.label}`;8}9console.log(badge.show());

Lines 1 to 4 make a badge whose show is the function on line 6. Line 7 reads this.label, but a plain function can be called on anything, so TypeScript can't know what this is. noImplicitThis marks it: 'this' implicitly has type 'any' because it does not have a type annotation. Line 9 does print Label: Cart; the check is about the calls TypeScript can't see. The fix is a this parameter, from this in TypeScript.

noUncheckedIndexedAccess: the item might not be there

Strict checks a find that might find nothing. It doesn't check an array index or a key that might not be there. You met the flag that does in Index signatures and Arrays and tuples. Here it is with the switch in your hands:

1const prices: Record<string, number> = { tea: 3, cake: 4 };2 3const jam = prices["jam"];4//    ^?5console.log(jam.toFixed(2));

Line 1 makes a price list with tea and cake. Line 3 reads the price of jam, and the query on line 4 shows its type. With Flag off, jam is a number, and line 5 crashes with no warning. With Flag on, it's number | undefined, and line 5 is marked. With a fallback uses ?? to pick 0 when jam is undefined and prints 0.00 (Nullish coalescing & optional chaining covers ??).

The flag doesn't make every array read harder. It only adds undefined where an item really might be missing:

1const cart = ["tea", "cake"];2const first = cart[0];3//    ^?4for (const item of cart) {5  //       ^?6  console.log(item.toUpperCase());7}8const pair: [string, number] = ["tea", 3];9const product = pair[0];10//    ^?

• Line 2 reads cart[0]. The query on line 3 says string | undefined: a string[] can be empty.
• Line 4 loops with for...of, and the query on line 5 says item is a string. A loop only visits items that are there (for...of and for...in). Line 6 prints TEA and CAKE.
• Line 8 makes a tuple, an array with a fixed length. Line 9 reads index 0, which always exists, so the query on line 10 says string.

So code that loops, or uses methods like map, rarely notices the flag. Code that picks items by position or by key gets an error wherever it forgot that the item might be missing.

exactOptionalPropertyTypes: left out is not undefined

A property marked with ?, like theme?: "light" | "dark", is optional: an object may leave it out. In JavaScript, leaving a key out and giving it the value undefined are two different objects:

const defaults = { theme: "light", fontSize: 16 };
const leftOut = {};
const setToUndefined = { theme: undefined };

console.log({ ...defaults, ...leftOut }.theme);
console.log({ ...defaults, ...setToUndefined }.theme);
console.log("theme" in setToUndefined);

Line 1 holds the defaults. Line 2 leaves theme out; line 3 has a theme key holding undefined. Lines 5 and 6 spread each one over the defaults (Spread and rest covers ...). Line 5 prints light: nothing replaced the default. Line 6 prints undefined: the key was copied, value and all. Line 7 prints true, because the key exists.

By default, TypeScript treats both the same way: theme?: allows undefined too. exactOptionalPropertyTypes makes ? mean only "may be left out". Try saving the theme in different ways:

1type Settings = { theme: "light" | "dark"; fontSize: number };2type SavedSettings = { theme?: "light" | "dark"; fontSize?: number };3 4const defaults: Settings = { theme: "light", fontSize: 16 };5const saved: SavedSettings = { theme: undefined };6const settings = { ...defaults, ...saved };7//    ^?8console.log(settings.theme);

With the flag off, line 5 is fine, and the query on line 7 says theme is "light" | "dark". Line 8 prints undefined anyway: the type made a promise the code broke. With the flag on, the same line 5 is marked, and the message ends with with 'exactOptionalPropertyTypes: true', so you know which flag is talking. Leave the theme out, or save a real one, and the error is gone. (Utility types showed the same flag with Partial.)

The flag also changes what you may write into an optional property later:

1type Profile = { nickname?: string; bio?: string | undefined };2 3const profile: Profile = { nickname: "Ash" };4profile.nickname = undefined;5delete profile.nickname;6profile.bio = undefined;

• Line 1 makes nickname optional, and bio optional with | undefined written out.
• Line 4 writes undefined into nickname and is marked: Type 'undefined' is not assignable to type 'string' with 'exactOptionalPropertyTypes: true'.
• Line 5 removes the key with delete, which is fine: now it's really left out.
• Line 6 writes undefined into bio, which is fine, because its type says undefined is allowed.

More checks outside strict

A few more flags catch mistakes that aren't about types at all. One is about classes. When a class extends another (Class inheritance), it can replace a method of its parent by giving its own method the same name. TypeScript has a keyword to say you mean it, override, and a flag that makes it required:

1class Widget {2  draw() {3    return "widget";4  }5}6 7class CartWidget extends Widget {8  draw() {9    return "cart";10  }11}12 13class BadgeWidget extends Widget {14  override render() {15    return "badge";16  }17}

• Lines 1 to 5 make a Widget with a draw method.
• Line 8 replaces draw in CartWidget without saying so. With noImplicitOverride on, that's marked: This member must have an 'override' modifier because it overrides a member in the base class 'Widget'.
• Line 14 says override, but Widget has no render. Maybe it was renamed to draw last week. TypeScript marks it: This member cannot have an 'override' modifier because it is not declared in the base class 'Widget'.

Together, the two errors keep classes in step with their parents. Once every replaced method says override, renaming the parent's method gets you an error in every child that still uses the old name.

1function shippingCost(country: string) {2  if (country === "IN") {3    return 0;4  } else if (country === "US") {5    return 5;6  }7}8 9console.log(shippingCost("FR"));

Lines 2 to 6 return a cost for India and for the US. For any other country the function reaches the end without a return, so line 9 prints undefined. noImplicitReturns marks line 1: Not all code paths return a value.

TypeScript 5.9's tsc --init, the command that writes a new tsconfig.json, turns two extra flags on and lists the rest as comments for you to consider. Read each row as: this flag, what it reports, and what tsc --init does with it.

Turning strictness up gradually

A new project should start with strict on. An older project with strict off can have hundreds of errors waiting. Turning everything on at once gives one huge change that's hard to finish. The safer path is one check at a time: turn it on, fix its errors, merge the change, then the next. Step through it on a small user list:

1type User = { name: string; email?: string };2 3const users: User[] = [4  { name: "Asha", email: "asha@example.com" },5  { name: "Ravi" },6];7 8function emailDomain(user) {9  return user.email.split("@")[1];10}11 12console.log(emailDomain(users[0]));

{
  "compilerOptions": {
    "strict": false
  }
}

Line 1 says a User may have an email, and line 5 is a user without one. Line 8 starts emailDomain, line 9 reads the part of the email after the @, and line 12 calls it. Steps 2, 4, and 7 each turn on one check and get one error. Steps 3, 5, and 8 fix it. Step 4 found a real bug: Ravi has no email, and line 9 would crash on him. Step 6 swaps the two flags for strict: true and finds nothing new in this code.

A few habits make this work in a real project:

• Start with noImplicitAny, then strictNullChecks. They find the most errors, and the rest of the group is usually quick after them.
• Or turn on strict and switch off the flags that aren't ready yet, as in the tsconfig.json above. Then deleting one false line is the whole next step.
• Merge each step on its own, so nobody waits on a change with hundreds of fixes.
• Add the extra flags last. noUncheckedIndexedAccess often finds the most errors of all in code that reads arrays by index.

Migrating JavaScript to TypeScript, later in this course, uses the same steps while moving a whole project from .js files to TypeScript.

The strict settings of a shop project

Here is a complete tsconfig.json for a shop's frontend built with a bundler like Vite. The output settings come from the next lesson; this one is about lines 6 to 11:

1{2  "compilerOptions": {3    "target": "es2022",4    "module": "esnext",5    "moduleResolution": "bundler",6    "strict": true,7    "noUncheckedIndexedAccess": true,8    "exactOptionalPropertyTypes": true,9    "noImplicitOverride": true,10    "noImplicitReturns": true,11    "noFallthroughCasesInSwitch": true,12    "noEmit": true13  },14  "include": ["src"]15}

• Line 6 turns on the strict group.
• Lines 7 and 8 add the two checks tsc --init also turns on: an item that might be missing, and undefined in an optional property.
• Lines 9 to 11 add three checks that catch mistakes in classes, returns, and switch statements.
• Line 12 says only check, don't write files, because the bundler builds the JavaScript.

Now sort the lines below by which setting reports them. Each one is checked on its own, with and without that setting.

Common mix-ups

The override keyword checks something even with the flag off. Here noImplicitOverride isn't set:

1class Page {2  load() {3    return "page";4  }5}6 7class CartPage extends Page {8  override reload() {9    return "cart";10  }11}

Line 8 says override reload(), but Page only has load. TypeScript marks it anyway and even asks Did you mean 'load'?. Writing override is always checked. What the flag adds is that leaving it out is an error too.

• "strict turns on every check TypeScript has." No. It turns on a group of nine in TypeScript 5.9. noUncheckedIndexedAccess, exactOptionalPropertyTypes, and noImplicitOverride are outside it.
• "Writing strict: true and strictNullChecks: false is a contradiction." No. It means "the whole group, except this one". A flag you write yourself wins over the group, wherever it sits in the file.
• "noUncheckedIndexedAccess makes every array read a chore." No. for...of loops, methods like map, and fixed tuple indexes are unchanged. Only reads that might miss get undefined.
• "A key set to undefined is the same as a key left out." No. A spread copies the undefined, and in finds the key. exactOptionalPropertyTypes keeps the two apart.
• "Turning on a stricter flag changes what my code does." No. The checks only change what TypeScript reports. The one exception is alwaysStrict: in a file that isn't a module, it also adds "use strict" to the JavaScript. A module is in strict mode already, so nothing changes there.
• "Once strict is on, upgrading TypeScript can't add errors." No. New versions may add checks to the group, so an upgrade can bring new errors. Turning one off by name is the way out while you fix them.

Practice exercises

Every exercise is TypeScript and lists the settings it's checked with under the code. Press Edit & run to change the code: the errors update as you type. Try a guess first, then use the hints.

try {
  JSON.parse("{ broken");
} catch (error) {
  console.log(error.name);
}

1try {2  JSON.parse("{ broken");3} catch (error) {4  if (error instanceof Error) {5    console.log(error.name);6  }7}

1const sizes = ["S", "M", "L"];2const firstSize = sizes[0];

1const sizes = ["S", "M", "L"];2const firstSize = sizes[0];3//    ^?

1const results = ["Green tea", "Black tea"];2 3function topResult(list: string[]) {4  return list[0].toUpperCase();5}6 7console.log(topResult(results));8console.log(topResult([]));

1const results = ["Green tea", "Black tea"];2 3function topResult(list: string[]) {4  return list[0]?.toUpperCase() ?? "No results";5}6 7console.log(topResult(results));8console.log(topResult([]));

1type Settings = { theme: "light" | "dark"; fontSize: number };2type SavedSettings = { theme?: "light" | "dark"; fontSize?: number };3 4const defaults: Settings = { theme: "light", fontSize: 16 };5const saved: SavedSettings = { theme: undefined, fontSize: 18 };6const settings = { ...defaults, ...saved };7console.log(`${settings.theme} ${settings.fontSize}`);

1type Settings = { theme: "light" | "dark"; fontSize: number };2type SavedSettings = { theme?: "light" | "dark"; fontSize?: number };3 4const defaults: Settings = { theme: "light", fontSize: 16 };5const saved: SavedSettings = { fontSize: 18 };6const settings = { ...defaults, ...saved };7console.log(`${settings.theme} ${settings.fontSize}`);

1class Widget {2  draw() {3    return "widget";4  }5}6 7class CartWidget extends Widget {8  draw() {9    return "cart (3)";10  }11}12 13console.log(new CartWidget().draw());

1class Widget {2  draw() {3    return "widget";4  }5}6 7class CartWidget extends Widget {8  override draw() {9    return "cart (3)";10  }11}12 13console.log(new CartWidget().draw());

1type Coupon = { code: string; percent: number };2const coupons: Coupon[] = [{ code: "TEA10", percent: 10 }];3 4function discounted(total, code: string) {5  const coupon = coupons.find((item) => item.code === code);6  return total - (total * coupon.percent) / 100;7}8 9console.log(discounted(20, "TEA10"));10console.log(discounted(20, "CAKE5"));

1type Coupon = { code: string; percent: number };2const coupons: Coupon[] = [{ code: "TEA10", percent: 10 }];3 4function discounted(total: number, code: string) {5  const coupon = coupons.find((item) => item.code === code);6  if (!coupon) return total;7  return total - (total * coupon.percent) / 100;8}9 10console.log(discounted(20, "TEA10"));11console.log(discounted(20, "CAKE5"));

Check your understanding

Each question names the settings it assumes. The quiz shows its code without the checker, so the error list doesn't give the answers away.

Key takeaways

• strict turns on a group of nine checks in TypeScript 5.9, each a flag with its own name, like noImplicitAny and strictNullChecks.
• A flag you write yourself wins over the group: strict: true with strictNullChecks: false keeps the rest on.
• noUncheckedIndexedAccess adds undefined to reads by index or key that might miss. Loops and tuples are unchanged.
• exactOptionalPropertyTypes makes ? mean "may be left out", not "may be undefined".
• noImplicitOverride, noImplicitReturns, and noFallthroughCasesInSwitch catch mistakes in classes, returns, and switch.
• In an existing project, turn checks on one at a time and fix each list before the next.

Coming next: target, lib & module. It covers the other half of tsconfig.json: which JavaScript tsc writes, which built-in types it knows, and how imports are found.