Every type in this course is only as trustworthy as the compiler settings behind it. The same Order type that catches a missing tracking number under one tsconfig waves a crash through under another. When I joined the migration I later led, the tsconfig had strict: false and the team was proud of its 100% TypeScript coverage. Most of that coverage was checking very little.
This lesson is about choosing flags deliberately, and about turning them on in a real codebase without a six-week freeze.
\nstrict is not one check but a family. The ones that matter most day to day:
| Flag | \nWhat it catches | \n
|---|---|
strictNullChecks | \nUsing a value that might be null or undefined | \n
noImplicitAny | \nParameters and variables silently typed any | \n
strictFunctionTypes | \nUnsafe callback parameter types (lesson 1-2) | \n
useUnknownInCatchVariables | \nTreating a caught value as an Error without checking | \n
strictPropertyInitialization | \nClass fields that are never assigned | \n
From TypeScript 6.0, strict is on by default, so a new project gets it without asking. For older projects it is still the single most valuable line in the file. Everything else in this lesson assumes it.
noUncheckedIndexedAccess makes index access honest. With it, lines[0] is Line | undefined and STOCK[sku] is number | undefined:
const first = cart.lines[0];\nfirst.sku;\n// Error: 'first' is possibly 'undefined'.\n\nconst available: number = STOCK[sku];\n// Error: Type 'number | undefined' is not assignable to type 'number'.“Cannot read properties of undefined” is the most common runtime error in JavaScript, and empty arrays and missing keys are its favourite sources. This flag catches them. The cost is some extra checks where you know an index is valid (inside for (let i = 0; i < xs.length; i++)); for…of loops and array methods like map are unaffected.
exactOptionalPropertyTypes separates “missing” from “present but undefined”. Cartwheel’s PATCH endpoint treats { couponCode: undefined } as “remove the coupon” and {} as “leave it alone”. Without the flag, both have the same type. With it:
type OrderPatch = { couponCode?: string };\nconst patch: OrderPatch = { couponCode: undefined };\n// Error: Type '{ couponCode: undefined; }' is not assignable to type 'OrderPatch'\n// with 'exactOptionalPropertyTypes: true'. …If you really mean “may be explicitly undefined”, say so: couponCode?: string | undefined. This flag is noisier to adopt, because many libraries’ types were written without it, so turn it on after the others.
TypeScript 5.9’s tsc --init now enables both flags by default in the tsconfig it generates, a strong hint about where the ecosystem is heading.
verbatimModuleSyntax (TypeScript 5.0) makes emitted imports match what you wrote. Any import without a type modifier is kept; imports marked type are erased. That matters because tools such as Vite, esbuild and Node’s built-in type stripping compile one file at a time and cannot look up whether Order is a type:
import { Order } from './orders';\n// Error: 'Order' is a type and must be imported using a type-only import\n// when 'verbatimModuleSyntax' is enabled.\n\nimport { type Order, placeOrder } from './orders'; // finemoduleResolution tells TypeScript how your imports are found. Match it to the tool that actually resolves them. For an app built by Vite or another bundler, use "bundler" (with "module": "esnext" or "preserve"): it understands package exports and does not require file extensions. For code that Node runs directly, such as a server or a CLI, use "module": "nodenext", which follows Node’s real rules, including .js extensions in relative imports. The old "node" setting (also called node10) predates package exports; it is deprecated in TypeScript 6.0 and removed in 7.0, along with baseUrl and target: "es5".
erasableSyntaxOnly (TypeScript 5.8) rejects the few TypeScript features that generate runtime code: enum, namespaces with values, constructor parameter properties, and the CommonJS-style import x = require(…) and export =. Turn it on if your code runs through Node’s type stripping or you want TypeScript to stay “JavaScript plus types”.
Put together, a tsconfig for a bundled app in 2026 looks like this:
\n{\n \"compilerOptions\": {\n \"target\": \"es2022\",\n \"module\": \"esnext\",\n \"moduleResolution\": \"bundler\",\n \"verbatimModuleSyntax\": true,\n \"erasableSyntaxOnly\": true,\n \"noEmit\": true,\n \"strict\": true,\n \"noUncheckedIndexedAccess\": true,\n \"exactOptionalPropertyTypes\": true,\n \"noImplicitOverride\": true,\n \"skipLibCheck\": true,\n \"jsx\": \"react-jsx\"\n },\n \"include\": [\"src\"]\n}noEmit because the bundler produces the JavaScript and tsc only checks. skipLibCheck because checking every .d.ts in node_modules costs time and finds problems you cannot fix.
Flip a flag on a big codebase and you might get 2,000 errors. Do not fix them all in one pull request. Measure first (tsc --noEmit | grep -c "error TS"), then pick one of two approaches. Either fix directory by directory using a separate tsconfig that extends the main one and includes only the clean folders, or turn the flag on everywhere and mark the existing errors with // @ts-expect-error plus a ticket reference, so new code is held to the new standard immediately and the old count only goes down.
The exercise is a scenario: three real bugs, and you pick the flags that would have caught them. The playground itself runs with strict and the ES2022 library, which is why some later features need a small declaration to work there, as you will see next.
strict is a family of checks (null checks, implicit any, function parameter checks and more), and it is the default from TypeScript 6.0 on.","noUncheckedIndexedAccess adds undefined to array and record lookups, which catches the most common crash that strict misses.","exactOptionalPropertyTypes separates a missing property from one explicitly set to undefined, which matters for PATCH bodies and spreads.","verbatimModuleSyntax makes the emitted imports match what you wrote, so type-only imports must say import type.","Use moduleResolution: "bundler" for apps built by Vite or another bundler, and nodenext for code that Node runs directly."],"further":[{"title":"TSConfig Reference","url":"https://www.typescriptlang.org/tsconfig/"},{"title":"noUncheckedIndexedAccess","url":"https://www.typescriptlang.org/tsconfig/noUncheckedIndexedAccess.html"},{"title":"Modules - Choosing Compiler Options","url":"https://www.typescriptlang.org/docs/handbook/modules/guides/choosing-compiler-options.html"},{"title":"TypeScript 6.0 release notes","url":"https://www.typescriptlang.org/docs/handbook/release-notes/typescript-6-0.html"}],"quiz":[{"q":"With strict on but noUncheckedIndexedAccess off, what happens here when the cart is empty?
const first = cart.lines[0];\nconsole.log(first.sku);lines[0] is typed as Line, not Line | undefined, so the empty case is invisible."},{"text":"It fails to compile, because strictNullChecks knows arrays can be empty.","why":"strictNullChecks only tracks null and undefined in declared types. Index access is optimistic unless noUncheckedIndexedAccess is on."},{"text":"It compiles and logs undefined.","why":"Reading .sku on undefined throws; it does not return undefined."},{"text":"It fails to compile, because strict forbids index access.","why":"Index access is always allowed; the flag only changes the resulting type."}],"answer":0},{"q":"type Patch = { couponCode?: string }. With exactOptionalPropertyTypes on, which value is rejected?
{}","why":"Leaving an optional property out is always allowed."},{"text":"{ couponCode: 'LOYAL5' }","why":"A string is exactly what the property allows."},{"text":"{ couponCode: undefined }","why":"Correct. The flag treats “present with value undefined” as different from “missing”; declare couponCode?: string | undefined if you mean to allow it."}],"answer":2},{"q":"Your file has import { Order, placeOrder } from './orders' where Order is a type. With verbatimModuleSyntax on, what do you write?
Order from the output automatically.","why":"That automatic elision is exactly what the flag turns off, so emitted imports match the source."},{"text":"import { type Order, placeOrder } from './orders'","why":"Correct. The type modifier marks Order as type-only, so it is erased while placeOrder stays."},{"text":"import * as orders from './orders' and use orders.Order","why":"A namespace import works for values, but it does not solve the type-only marking the flag asks for."},{"text":"Turn on esModuleInterop.","why":"esModuleInterop is about CommonJS default imports and is unrelated to type-only imports."}],"answer":1},{"q":"Your Vite app has "moduleResolution": "node" in its tsconfig. What should you change it to, and why?
"classic", because it is the most permissive.","why":"classic predates npm conventions, and like node it is deprecated in TypeScript 6.0 and removed in 7.0."},{"text":""nodenext", because Vite runs on Node.","why":"Vite runs on Node, but your app code is resolved by the bundler, and nodenext would demand file extensions the bundler does not need."},{"text":""bundler", because it models how Vite resolves imports, including package exports, and node is deprecated.","why":"Correct. bundler matches the tool that actually resolves your imports, and node (node10) is removed in TypeScript 7.0."}],"answer":2}],"exercise":{"kind":"choice","multiple":true,"options":["unchecked-index","exact-optional","implicit-override","skip-lib-check","verbatim-modules","allow-js"],"correct":["unchecked-index","exact-optional","implicit-override"],"title":"Which flags would have caught these bugs?","prompt":"Cartwheel’s checkout already compiles with strict: true. These three bugs still reached production last quarter:
cart.lines[0].sku to show a thumbnail. For an empty cart, the page crashed with Cannot read properties of undefined.{ couponCode: formValue.coupon } to the PATCH endpoint. formValue.coupon is typed string | undefined (the field is optional); when it was empty, the value was undefined, and the API treats a present-but-undefined couponCode as “remove the coupon”, so customers lost coupons they had applied earlier.PriceCalculator.applyTax() was renamed to addTax() in the base class. The subclass GulfPriceCalculator still defined applyTax(), which now overrode nothing, so Gulf orders were taxed with the default rate.Select every compiler flag that, added to strict, would have turned at least one of these bugs into a compile error.
cart.lines[0] has today, and which flag changes it.","One flag distinguishes {} from { couponCode: undefined } for an optional property.","One flag requires the override keyword on every method that overrides a base-class method, so a stale override stops compiling."],"explanation":"noUncheckedIndexedAccess types cart.lines[0] as Line | undefined, forcing a check before .sku (bug 1). exactOptionalPropertyTypes rejects assigning undefined to couponCode?: string, so the form would have had to omit the key or declare string | undefined explicitly (bug 2). noImplicitOverride requires override applyTax() in the subclass; once the base method is renamed, override on a method that overrides nothing is an error (bug 3). skipLibCheck reduces checking, verbatimModuleSyntax is about how imports are emitted, and allowJs lets JavaScript files into the program; none of them catches these bugs.
noUncheckedIndexedAccess","why":"Correct. It makes cart.lines[0] possibly undefined, so reading .sku without a check is an error (bug 1)."},"exact-optional":{"text":"exactOptionalPropertyTypes","why":"Correct. It forbids writing undefined into couponCode?: string, which is exactly the value that removed coupons (bug 2)."},"implicit-override":{"text":"noImplicitOverride","why":"Correct. With it, the subclass must mark override applyTax(), and that marker fails once the base method is renamed (bug 3)."},"skip-lib-check":{"text":"skipLibCheck","why":"It skips type-checking declaration files, mostly in node_modules. It makes checking faster and looser, never stricter."},"verbatim-modules":{"text":"verbatimModuleSyntax","why":"It controls which imports are kept in the emitted JavaScript. It is valuable for bundlers, but it does not check property access or overrides."},"allow-js":{"text":"allowJs","why":"It lets .js files join the program. It is a migration tool and adds no checks to existing TypeScript code."}}},"words":815,"readMinutes":4}