TypeScript Strict Mode
debt(d5/e7/b7/t7)
Closest to 'specialist tool catches it' (d5). The detection_hints list TypeScript compiler and ESLint as tools, and the code_pattern explicitly identifies tsconfig.json without strict:true. The TypeScript compiler itself will flag errors once strict is enabled, but the absence of strict mode is not caught by a default linter rule — you need to deliberately inspect tsconfig or run a TypeScript-aware config linter to detect the omission, placing it at the specialist tool level.
Closest to 'cross-cutting refactor across the codebase' (e7). The quick_fix says add 'strict': true to tsconfig.json, which is a one-liner, but the common_mistakes explicitly warn that adding it later requires fixing hundreds of type errors across the codebase. This is inherently cross-cutting — every file with implicit any, null/undefined assumptions, or non-null assertions must be visited and corrected, making the remediation effort span the entire project.
Closest to 'strong gravitational pull' (b7). The applies_to covers web and cli contexts broadly, and the choice shapes every future type annotation decision across the entire codebase. Without strict mode, every maintainer is working with a weakened type system, and the misconception field notes it creates a false sense of type safety. Third-party library usage is also affected under strict mode per common_mistakes, meaning the burden extends to integration points as well. Every new file, every new developer, and every dependency is shaped by this foundational configuration choice.
Closest to 'serious trap — contradicts how a similar concept works elsewhere' (t7). The misconception field explicitly states developers believe strict mode is too restrictive for real projects, when in fact it is the recommended default. This directly contradicts the intuition that type-checking strictness should be relaxed for pragmatic production use. Additional traps include the non-null assertion operator (!) appearing to satisfy the type checker while being a runtime lie, and the surprise that enabling strict mode retroactively breaks previously-compiling code — all documented in common_mistakes as serious gotchas.
Also Known As
TL;DR
Explanation
strict: true in tsconfig.json enables: strictNullChecks (null/undefined are not assignable to other types), noImplicitAny (implicit any is an error), strictFunctionTypes (stricter function parameter checking), strictPropertyInitialization (class properties must be initialised), and more. Most TypeScript bugs caught in the wild are prevented by strictNullChecks alone. Starting with strict: true from day one is far cheaper than enabling it on an existing codebase.
Common Misconception
Why It Matters
Common Mistakes
- Not enabling strict mode on new projects — adding it later requires fixing hundreds of type errors.
- Disabling specific strict checks to silence errors instead of fixing the underlying type issue.
- Using non-null assertion (!) to bypass strictNullChecks — this is a runtime lie; validate instead.
- Not realising strict mode affects third-party library usage — some older libraries have poor types under strict mode.
Code Examples
// Without strictNullChecks — null errors invisible:
function getUsername(user: User): string {
return user.name.toUpperCase(); // No error even if name is null
}
// Runtime: TypeError: Cannot read properties of null (reading 'toUpperCase')// tsconfig.json:
{ "compilerOptions": { "strict": true } }
// With strictNullChecks — null must be handled:
function getUsername(user: User): string {
if (!user.name) return 'Anonymous';
return user.name.toUpperCase(); // TypeScript knows name is string here
}
// Or with optional chaining:
function getUsername(user: User): string {
return user.name?.toUpperCase() ?? 'Anonymous';
}