Strict Compiler Flags in tsconfig.json
Quick Overview
`strict` is a bundle, not a single flag: it turns on `noImplicitAny`, `strictNullChecks` and six others at once. `noUncheckedIndexedAccess` sits outside it, making `arr[0]` admit it may be `undefined`.
Deep Dive
1. Configuring Type Rigor
TypeScript's type checking rigor is configured inside tsconfig.json. Enabling strict compiler flags turns TypeScript into an uncompromising production quality gate.
2. The Master Flag: "strict": true
Enabling "strict": true automatically turns on a family of strict type checking flags:
noImplicitAny: Throws a compile error if a variable or parameter type cannot be inferred and defaults implicitly toany.strictNullChecks: Ensuresnullandundefinedare not assignable to other types unless explicitly unioned.strictFunctionTypes: Enforces strict bivariance checks on function parameters.strictBindCallApply: Ensures arguments passed to.call(),.apply(), and.bind()match underlying function signatures.
3. High-Value Optional Flag: noUncheckedIndexedAccess
By default, reading dynamic object or array indices (e.g. arr[0] or dict["key"]) returns the value type. Enabling noUncheckedIndexedAccess: true forces array/object lookups to include | undefined:
// tsconfig.json -> "noUncheckedIndexedAccess": true
const list: string[] = ["Alex"];
const item = list[5]; // Inferred type: string | undefined (Forces safe checking!)
4. Essential Production tsconfig Snippet
{
"compilerOptions": {
"target": "ES2022",
"module": "NodeNext",
"moduleResolution": "NodeNext",
"strict": true,
"noImplicitAny": true,
"strictNullChecks": true,
"noUncheckedIndexedAccess": true,
"noImplicitReturns": true,
"skipLibCheck": true
}
}
5. Common Mistakes
- Disabling Strict Flags to Finish Fast: Disabling strict flags hides bugs until they crash in production. Keep
strict: trueenabled on all codebases!
6. Next Steps
Enable strict flags on every project. Next, let's explore ECMAScript Decorators in TypeScript 5.0+!
Next Up in TypeScript & Type System Mechanics
TypeScript Primitives & Explicit Type Annotations
TypeScript erases entirely at build time, so a `string` annotation produces no runtime check whatsoever. A value arriving from an API is whatever the server actually sent, regardless of what the annotation claims.
Type Inference & Literal Types (const vs. let)
`let x = "GET"` infers `string` because the binding can change; `const x = "GET"` infers the literal `"GET"`. That widening rule is why object properties need `as const` to stay narrow.
Arrays, Tuples & Readonly Modifiers
`string[]` is any number of strings; `[string, number]` is exactly two, in that order. `readonly` removes the mutating methods at compile time, so `push` becomes a type error rather than a runtime surprise.
