Correctness Flags Beyond strict

## `strict` is a shorthand, not a mode In tsconfig.json, `strict` is one option that switches on a fixed family of related options in a single line. It is a shorthand for listing that family individually; the compiler still tracks each member as its own option, which is why you can set `strict` and then name one family member explicitly to change just that one. What matters here is the boundary: the family it covers is aimed at *soundness of the type model* (things the checker would otherwise be silently guessing about), and TypeScript deliberately keeps a second set of correctness checks outside it. As of TypeScript 6.0 that split is unchanged. ## The checks that stay off Each of these is an independent boolean in `compilerOptions`, and each stays `false` no matter what `strict` is set to: - **`noUncheckedIndexedAccess`** — a read through an array index or an index signature gains `| undefined`, so `rows[0]` on a `string[]` is `string | undefined`. - **`exactOptionalPropertyTypes`** — `retries?: number` stops silently meaning `number | undefined`; a *present* property must hold a real `number`, and writing `{ retries: undefined }` is an error unless you declare `retries?: number | undefined`. - **`noPropertyAccessFromIndexSignature`** — a key that exists only through an index signature must be read with brackets. Given `type Env = { [k: string]: string }`, `env.HOME` errors and `env["HOME"]` is required, so dot access stays a signal that the property was actually declared. - **`noImplicitOverride`** — a member that redefines a concrete base-class member must be written with the `override` keyword. - **`noImplicitReturns`** — a function where some code paths return a value and control can also fall off the end is an error. - **`noFallthroughCasesInSwitch`** — a `case` clause that contains statements and then falls into the next clause is an error. Empty grouped labels (`case 'a': case 'b':`) are still fine, because nothing falls through them. - **`noUnusedLocals`** and **`noUnusedParameters`** — a local or parameter that is declared and never read is an error. - **`allowUnreachableCode`** and **`allowUnusedLabels`** — left unset, unreachable code and unused labels surface only as editor hints; setting them to `false` promotes them to errors. ```json { "compilerOptions": { "strict": true, "noUncheckedIndexedAccess": true, "exactOptionalPropertyTypes": true, "noPropertyAccessFromIndexSignature": true, "noImplicitOverride": true, "noImplicitReturns": true, "noFallthroughCasesInSwitch": true, "noUnusedLocals": true, "noUnusedParameters": true } } ``` ## Why the split exists Two different kinds of pickiness are involved. The `strict` family mostly closes holes where the checker had *no information* — it makes the compiler stop assuming a value can never be null or that an unannotated parameter is fine. The beyond-strict flags mostly disagree with code the author already believes is correct: your loop really does index inside bounds, your options object really does pass `undefined` for a default, your unused import really is about to be used. That is why they are noisy, and why turning them on is a code-change project rather than an annotation-adding project. Keeping them out of `strict` means a codebase can commit to `strict` without also committing to that project. There is also a subtler reason for `noUncheckedIndexedAccess` and `exactOptionalPropertyTypes` specifically: both make the type model *more accurate* at the cost of forcing a check at every use site, and whether that trade pays depends on the codebase. A service that reads a lot of dictionaries benefits enormously; a codebase full of fixed-shape objects mostly gets friction. ## They change checking, never output All of these are check-only. TypeScript erases its type layer at emit, and none of these flags inserts a runtime guard, strips an unused declaration, or alters the JavaScript in any way — they only decide which programs the compiler accepts. That makes each one cheap to try: flip it, look at the error count, and revert if the team is not ready. It also means `noUnusedLocals` is not dead-code elimination; the unused declaration is still emitted, you are simply told about it. ## The boundary people get wrong Unused code, fallthrough cases and missing returns are the classic province of a linter, so candidates often assume these are lint rules rather than compiler options. They are compiler options, they produce ordinary type-check errors, and they fail `tsc` and therefore CI. Deciding whether the compiler or the linter should own a given rule is a real team decision — but it is a decision, not a fact about where the check lives.