You set "strict": true in the tsconfig.json of an established TypeScript codebase and tsc reports several thousand errors. How do you get the project onto strict without a big-bang rewrite?

## The error count is not the problem A five-figure error count from one boolean is the expected outcome, not a signal that the codebase is bad. `strict` is eight or more independent checks, and one of them — `strictNullChecks` — changes the type of every declaration in the program at once. The first move is to stop looking at the aggregate number and get a per-flag breakdown, because that is what decides the plan. ## Split by flag Enable one member at a time, on a scratch branch, and count: - `alwaysStrict`, `noImplicitThis`, `strictBindCallApply`, `useUnknownInCatchVariables` and `strictFunctionTypes` typically produce tens of errors in a mature codebase. They can often be fixed and merged the same day, and each one that lands is a check you never have to think about again. - `strictPropertyInitialization` is medium-sized and concentrated in classes, so it is bounded by how object-oriented the code is. - `noImplicitAny` and `strictNullChecks` are the two that produce thousands. Do them last, and do them differently. This alone often gets a project to "strict except two flags" in a week, which is a far better place to sit than "strict is off" — and the config says so explicitly: ```json { "compilerOptions": { "strict": true, "strictNullChecks": false, "noImplicitAny": false } } ``` ## Why `strictNullChecks` cannot be done per file There is no per-file pragma for it. The flag alters what `string`, `Foo` and every other type mean throughout the program, so a file compiled under it and a file compiled without it do not share a type system. Any "file by file" scheme must therefore work at the level of a *compilation*, not a directive. ## The growing-allowlist config The standard answer is a second tsconfig: ```json { "extends": "./tsconfig.json", "compilerOptions": { "strict": true, "noEmit": true }, "files": ["src/util/date.ts", "src/util/money.ts"] } ``` The main build stays as it is; CI additionally runs `tsc -p tsconfig.strict.json`. A file enters the list only when it and its dependencies check clean, and the list never shrinks. Because `files` pulls in each listed file's imports, the natural order of work falls out of the dependency graph: leaves first — shared utilities, domain types, constants — then the modules above them. Doing it in the other direction means re-fixing the same call sites as the types beneath them change. Where the repo is already split into packages, project references give you the same ratchet at package granularity, letting each package adopt `strict` on its own schedule. ## The alternative ratchet If a second config is awkward, the other workable mechanism is a baseline: record today's error count (or a checked-in list of erroring files) and fail CI if it increases. It is cruder — it does not stop a fixed file from regressing unless you track per file — but it is cheap and it stops the hole getting deeper while the team digs. ## Suppression hygiene The migration succeeds or fails on this point. `as any`, a non-null `!`, and `// @ts-ignore` all turn an error into silence, and a codebase that reaches "strict, zero errors" through them is strictly worse than before, because the config now claims a safety that is not there. - Prefer `// @ts-expect-error` with a short reason. It behaves like `@ts-ignore` except that it *errors when the line stops having an error*, so suppressions delete themselves as the underlying types improve. Every one is a to-do the compiler tracks for you. - Ban bulk codemods that insert `!` or `as any`. A hand-written narrowing at each site is the actual work; automating it away is skipping it. - Treat `// @ts-nocheck` on a whole file as a last resort with an owner and a date. ## Sequencing the human side Make the strict list a required check so new files start clean — that is the highest-value single step, because greenfield code is free to write correctly and expensive to retrofit. Give the migration a visible counter (files on the list, of total). Fold conversions into work already touching the file rather than running a separate, competing workstream; a file being modified is being tested anyway. ## What done looks like Done is `"strict": true` in the single base config, no per-flag overrides, no `@ts-expect-error` left that hides a real modelling gap, and the second config deleted. Reaching it in stages is normal; what matters is that every stage is enforced by CI rather than by intention.