Your team wants to adopt TypeScript's beyond-strict correctness flags — noUncheckedIndexedAccess, exactOptionalPropertyTypes and noUnusedLocals — on a large existing codebase. How would you sequence the rollout, and which flag do you expect to cost the most?

## Step one: measure, do not guess These are independent booleans, and the compiler will honour a single one passed on the command line over your existing configuration. So the size of each project is knowable before you commit to it: ```bash npx tsc --noEmit --noUncheckedIndexedAccess npx tsc --noEmit --exactOptionalPropertyTypes npx tsc --noEmit --noUnusedLocals ``` Count the errors, and also look at their *shape* — a thousand errors that are all the same index-loop pattern is a different project from a hundred spread across unrelated modules. This ten-minute exercise replaces the usual argument about which flag is "worth it" with numbers. ## Step two: one flag per change Adopt them one at a time, each as its own pull request that both enables the flag and fixes everything it surfaced. A combined rollout is unreviewable: reviewers cannot tell which edit answers which rule, and if one flag has to be reverted the others go with it. One flag per change also lets you stop — a team can decide after two that the third is not worth it, and that is a legitimate outcome rather than a half-finished migration. Where the codebase is split into packages or directories with their own tsconfig, enabling a flag in one low-traffic area first is a cheap way to learn its real cost and to produce examples of the intended fix before it lands everywhere. ## Step three: expect the flags to cost very different things **`noUncheckedIndexedAccess`** is usually the largest by an order of magnitude. Every C-style index loop and every `Record` lookup produces an error, because a length check does not narrow an index and never will. Most fixes are mechanical — hoist the read into a local and guard it, supply a `??` fallback, or switch to `for...of`, which is unaffected — but the volume is real. Its danger is not volume, though; it is the temptation to clear the wave with assertions. An assertion tells the compiler to believe exactly the claim the flag was questioning, so the codebase ends up with the pre-flag guarantees plus punctuation that implies someone verified the access. If the review norm is not established up front — real guard, real fallback, or iteration — the rollout is worse than not doing it. **`exactOptionalPropertyTypes`** produces far fewer errors, but they resist automation. Each one asks a design question: does this property genuinely accept an explicit `undefined`, in which case widen the declaration, or should the key simply not be written, in which case fix the construction site. No codemod can answer that, so budget reviewer attention rather than volume, and expect the errors to cluster in options-merging and update-style code. **`noUnusedLocals`** is nearly free to fix and the most annoying to live with. Delete a call while debugging and the build breaks on the now-unused import. There is also a trap worth knowing concretely: the leading-underscore convention exempts unused *parameters* under `noUnusedParameters` and unused bindings in array destructuring, but a plain unused *local* named `_thing` is still reported. Teams that assume the underscore is a universal opt-out get surprised. This is the flag most reasonably delegated to a linter, where it can be a warning with an autofix rather than a build failure. ## Step four: keep one configuration The editor and CI must read the same tsconfig. If a flag is enabled only in a CI-specific configuration, developers meet the errors at the worst possible moment and lose the fast feedback that makes the fixes cheap. If you must stage adoption, stage it by *scope* — which files a stricter configuration covers — not by *environment*. ## The reassurance that makes this easy to sell None of these flags changes a byte of emitted JavaScript. TypeScript erases its type layer, and none of these options injects a runtime check or removes a declaration. The rollout therefore cannot alter production behaviour on its own; the only behaviour changes are the ones you deliberately make while fixing errors. That is the argument that gets the flag turned on, and it is also the reason to review the fixes carefully — the risk lives entirely in the edits, not in the configuration. ## What a good answer sounds like Measure, sequence, one flag per change, name the expensive one and why, name the failure mode of a fast fix, and state that emit is unchanged. A weak answer flips everything on at once and reports the error count as an achievement.