production · 24 minute study
Compiler settings are part of architecture
A project can appear typed while unchecked indexes, unsafe assertions and transport casts leave its real boundaries fragile.
Useful preparation · 1 prerequisite
Use this as a map, not a lock. If these ideas are familiar, continue.
- Type components around ownership — Good component types show who owns state, what events mean and which combinations of props are valid.
First, build a mental model
Compiler options decide which uncertainties become visible. A clean typecheck is evidence about a particular program under a particular configuration, not proof that the product works.
- strict enables a family of checks, including null and function checking.
- noUncheckedIndexedAccess and exactOptionalPropertyTypes are separate opt-in checks; strict does not imply them.
- import type documents a compile-time dependency and is erased.
- Native Node type stripping and transpileModule do not replace tsc semantic checking.
{
"compilerOptions": {
"strict": true,
"noUncheckedIndexedAccess": true,
"exactOptionalPropertyTypes": true,
"noEmit": true
}
}- Source
The compiler reads the project and its dependencies.
- Options
Unchecked indexes can become T | undefined; omitted optional fields differ from explicitly undefined fields.
- Evidence
Diagnostics describe compile-time consistency, not authorization or tested runtime behavior.
Production thinking
Take this beyond the example.
Treat typecheck, runtime tests, build, deployment and production acceptance as separate claims. Fix the cause of diagnostics before considering assertions or suppression.
Sources and further reading
Your evidence
unseen is a local learning signal, not a credential or proof of production competence.
Explain the mental model, then explicitly acknowledge it. Opening a page is not evidence.
Supported retries can complete this lesson. Independent evidence and delayed review determine the skill stage.