TypeScript Strict Mode Won — Here's How to Use It Right

TypeScript's dominance is no longer debatable: it is the most-used language on GitHub, approaching majority status in the JavaScript ecosystem, and its compiler will soon ship with strict mode enabled by default. The State of JavaScript 2025 survey, published in February 2026, found that 40% of respondents now code exclusively in TypeScript — a figure the survey organizers say "keeps increasing and may soon represent a majority." Daniel Roe, leader of the Nuxt core team, declared in the survey's conclusion: "TypeScript has won. Not as a bundler — but as a language." One day later, the TypeScript team announced the TypeScript 6.0 beta, the final JavaScript-based release before the Go-powered TypeScript 7.0 delivers 10x build speed improvements. This convergence — ecosystem dominance, native runtime support in Node.js, and a performance revolution — makes strict type safety not a nice-to-have but the defining practice that separates production-grade TypeScript from a false sense of safety.

This guide combines the latest survey data, every compiler flag you should enable, production-tested patterns, and a data-backed argument that TypeScript's rise and strict type safety are inseparable.

The data proving TypeScript's dominance is overwhelming

The evidence spans every major developer survey conducted in 2024 and 2025. The GitHub Octoverse 2025 report recorded the most significant language shift in over a decade: TypeScript became the #1 language on GitHub by monthly contributors in August 2025, with 2.64 million monthly contributors — a staggering 66.6% year-over-year increase that surpassed even Python. The State of JavaScript 2024 survey (~23,500 respondents) found that 67% of developers write more TypeScript than JavaScript and 80% write at least half their code in TypeScript. The follow-up State of JavaScript 2025 survey (~12,000 respondents) escalated the trend: 40% now write only TypeScript, up from 34% the previous year.

The JetBrains Developer Ecosystem 2024 survey ranked TypeScript #1 on its new "Language Promise Index" — a composite metric of five-year growth, adoption intent, and user retention — ahead of Rust and Python. Stack Overflow's 2024 survey pegged TypeScript usage at 38.5% among all developers and 43.4% among professionals, ranking it fifth globally but first among languages that don't predate the web. Meanwhile, the TypeScript compiler sees over 60 million npm downloads per week, triple the figure from 2021.

The connection between this dominance and strict typing is inferential but strong. The State of JavaScript surveys have asked about JavaScript's biggest pain points every year since 2020, and the answer has never changed: "lack of a built-in type system" is the #1 complaint every single year. A 2025 academic study found that 94% of LLM-generated compilation errors are type-check failures, which directly explains why GitHub's Octoverse report ties TypeScript's surge to AI-assisted coding — types serve as guardrails that make Copilot and similar tools dramatically more reliable. Every major framework now scaffolds TypeScript by default: Next.js 15, Angular 18, SvelteKit 2, Astro 3, Remix, SolidStart, and Qwik all generate strict: true out of the box.

Key survey data summary:

The State of JavaScript 2025 survey also revealed ecosystem-level friction that matters for this discussion. Webpack, used by 86% of respondents, is disliked by 37% — called an "absolute nightmare to configure." Next.js, used by 59%, draws complaints about Vercel-centricity and mounting complexity. Vite, by contrast, earned 56% positive sentiment at 84% usage, and Daniel Roe pronounced 2026 "the year to opt into Vite." These ecosystem shifts reinforce TypeScript's centrality: the tooling debate has moved downstream to bundlers and meta-frameworks, while the language question is settled.

What strict: true actually enables — and why it's not enough

The strict flag in tsconfig.json is shorthand for nine individual compiler options. As of TypeScript 5.6, enabling "strict": true activates the following:

strictNullChecks (TS 2.0) treats null and undefined as distinct types, preventing the "billion dollar mistake" of null reference errors. noImplicitAny (TS 1.0) errors when TypeScript infers any for untyped parameters. strictFunctionTypes (TS 2.6) enforces contravariant parameter checking — a function expecting MouseEvent won't silently accept one expecting Event. strictBindCallApply (TS 3.2) type-checks bind, call, and apply arguments. strictPropertyInitialization (TS 2.7) requires class properties to be initialized. noImplicitThis (TS 2.0) errors when this has an implicit any type. useUnknownInCatchVariables (TS 4.4) types catch clause variables as unknown rather than any. alwaysStrict (TS 2.1) emits JavaScript strict mode. And the newest addition, strictBuiltinIteratorReturn (TS 5.6), ensures built-in iterators use undefined instead of any for their return type.

But strict: true leaves critical gaps. Matt Pocock, the most prominent TypeScript educator and author of Total TypeScript, put it bluntly in an April 2024 tweet that garnered over 102,000 views: "If you're not using strict: true in your tsconfig.json, you're not using TypeScript." He then went further, arguing that several flags excluded from strict should be considered essential. The three most important are:

noUncheckedIndexedAccess (TS 4.1) is arguably the single most valuable flag not in strict. Without it, arr[0] on a string[] returns string — even if the array is empty. With it, the return type becomes string | undefined, forcing you to handle the case. Pocock says this flag "should really be included in strict."

// Without noUncheckedIndexedAccess — UNSAFE
const users: string[] = [];
const first = users[0]; // type: string — but it's undefined at runtime! 💥
first.toUpperCase();     // Runtime crash, no compiler error

// With noUncheckedIndexedAccess — SAFE
const first = users[0]; // type: string | undefined ✅
first?.toUpperCase();    // Must handle the undefined case

exactOptionalPropertyTypes (TS 4.4) distinguishes between a property being absent and being explicitly set to undefined. This matters for APIs where "key" in obj and obj.key !== undefined should behave differently:

interface Settings {
  colorTheme?: "dark" | "light";
}
const s: Settings = { colorTheme: undefined }; // ❌ Error with exactOptionalPropertyTypes
const s: Settings = {};                        // ✅ Property is correctly absent

noPropertyAccessFromIndexSignature (TS 4.2) forces bracket notation for index signature properties, making it visually clear when you're accessing a known property versus a dynamic one.

The maximum-strictness tsconfig for 2026

TypeScript 5.9 updated tsc --init to generate a more opinionated configuration, and the TypeScript team has committed (GitHub issue #62333) to making --strict the default in TypeScript 6.0. The new tsc --init defaults now include noUncheckedIndexedAccess and exactOptionalPropertyTypes. Here is the recommended maximum-strictness configuration, synthesized from the TypeScript team's direction, Matt Pocock's Total TypeScript cheat sheet, and the community @tsconfig/strictest package:

{
  "compilerOptions": {
    // Core strict mode (9 flags)
    "strict": true,

    // Beyond-strict type safety (the critical extras)
    "noUncheckedIndexedAccess": true,
    "exactOptionalPropertyTypes": true,
    "noPropertyAccessFromIndexSignature": true,
    "noImplicitReturns": true,
    "noImplicitOverride": true,
    "noFallthroughCasesInSwitch": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "allowUnreachableCode": false,
    "allowUnusedLabels": false,

    // Module safety
    "verbatimModuleSyntax": true,
    "isolatedModules": true,
    "noUncheckedSideEffectImports": true,
    "moduleDetection": "force",
    "forceConsistentCasingInFileNames": true,

    // TS 5.8+ (for Node.js native type stripping)
    "erasableSyntaxOnly": true,

    // Environment
    "target": "es2022",
    "module": "nodenext",
    "skipLibCheck": true
  }
}

The erasableSyntaxOnly flag, introduced in TypeScript 5.8, deserves special attention. It errors on TypeScript constructs that generate runtime JavaScript — enums, namespaces, and parameter properties. This flag aligns with Node.js's native TypeScript execution (stable since Node.js 25.2.0, November 2025), which strips type annotations at runtime but cannot handle syntax that requires code generation. Enabling erasableSyntaxOnly forces you toward the future of TypeScript: a pure type layer over JavaScript with zero runtime footprint.

verbatimModuleSyntax (TS 5.0) eliminates import ambiguity by requiring explicit import type for type-only imports. This prevents TypeScript from silently eliding imports that might have side effects and produces predictable build output across bundlers. noUncheckedSideEffectImports (TS 5.6) complements this by erroring when side-effect imports like import "module" can't be resolved — catching typos and missing ambient declarations.

TypeScript 5.7 and 5.8 raised the strictness bar

TypeScript 5.7 (November 2024) introduced detection of variables that are declared but never assigned anywhere in scope — previously, only possibly uninitialized variables triggered errors. It also added --rewriteRelativeImportExtensions for writing .ts imports that compile to .js, and V8 compile cache support that delivers 2–3x faster startup on large projects.

TypeScript 5.8 (March 2025) delivered two significant strictness improvements. First, granular return expression branch checking: TypeScript now evaluates each branch of ternary expressions in return statements independently against the declared return type. Previously, if one branch returned any (common with Map.get()), the any infected the union and masked bugs in other branches:

declare const cache: Map<any, any>;

function getUrl(value: string): URL {
  return cache.has(value) ? cache.get(value) : value;
  //                                           ~~~~~
  // ❌ NEW in 5.8: Type 'string' is not assignable to 'URL'
  // Previously NO error because any | string simplified to any
}

Second, TypeScript 5.8 added the erasableSyntaxOnly flag and --module node18 as a stable (non-rolling) module option. The release also enabled CommonJS modules to require() ESM under --module nodenext, matching Node.js 22+ behavior and reducing the need for dual-publishing.

TypeScript 6.0 (beta February 11, 2026) is the bridge release to the Go-based TypeScript 7.0. It adds Temporal API types, inference improvements, ES2025 target support, and a --stableTypeOrdering flag for aligning output with TypeScript 7.0's deterministic behavior. Critically, TypeScript 6.0 is the last JavaScript-based release — only security patches will follow. TypeScript 7.0, written in Go, promises 8–10x faster builds and editor responsiveness on real-world projects.

Production patterns that strict mode enables

Strict mode isn't just about catching bugs — it enables architectural patterns that would be unsafe or meaningless without it. These patterns represent the current best practices in production TypeScript codebases.

Discriminated unions replace enums in strict-first codebases. Unlike enums, which generate runtime JavaScript and can't carry associated data per variant, discriminated unions provide exhaustive pattern matching with zero runtime cost:

type ApiState<T> =
  | { status: "idle" }
  | { status: "loading" }
  | { status: "success"; data: T }
  | { status: "error"; error: Error };

function render<T>(state: ApiState<T>) {
  switch (state.status) {
    case "success": return state.data;  // TS knows `data` exists here
    case "error":   return state.error; // TS knows `error` exists here
    // Missing a case? The exhaustiveness check catches it at compile time
  }
}

Branded types solve TypeScript's structural typing problem for domain identifiers. Without them, a UserId and OrderId are both string and freely interchangeable — a class of bug that strict mode alone doesn't catch:

type Brand<K, T> = K & { readonly __brand: T };
type UserId  = Brand<string, "UserId">;
type OrderId = Brand<string, "OrderId">;

function getUser(id: UserId): User { /* ... */ }
const orderId = "ord_123" as OrderId;
getUser(orderId); // ❌ Compile error: OrderId is not assignable to UserId

The satisfies operator (TS 4.9) validates that a value conforms to a type without widening the inferred type — the best of both worlds between type safety and type precision:

const routes = {
  home:  { path: "/", component: "Home" },
  about: { path: "/about", component: "About" },
} satisfies Record<string, { path: string; component: string }>;

routes.home.path; // type: "/" (narrow literal, not widened to string)

Zod and runtime validation complete the strict-mode story. Zod, which requires strict: true in tsconfig.json, provides a single source of truth for both compile-time types and runtime validation — essential for API boundaries, form inputs, and any data entering the system from the outside:

const UserSchema = z.object({
  id: z.string().uuid(),
  email: z.string().email(),
  role: z.enum(["admin", "editor", "viewer"]),
});
type User = z.infer<typeof UserSchema>; // Type derived from schema — no duplication

const result = UserSchema.safeParse(untrustedInput);
if (result.success) {
  result.data.email; // Fully typed, validated at runtime
}

Next.js 15 treats strict TypeScript as a first-class requirement

Next.js 15 enables "strict": true by default in every new project created with create-next-app. It also ships a custom TypeScript plugin ({ "name": "next" }) that provides type-checking for Server Components, Client Components, and the App Router's conventions. Typed routes, stable since Next.js 15.5, generate compile-time validated <Link href> props from your file system structure — a typo in a route string becomes a TypeScript error:

// With typedRoutes: true in next.config.ts
<Link href="/dashbord">Dashboard</Link>
//         ~~~~~~~~~~~ ❌ Type error: no route matches "/dashbord"

Next.js 15.5 also introduced global route type helpers (LayoutProps<'/dashboard'>, PageProps<'/users/[id]'>) that provide fully typed parallel route slots and dynamic parameters without imports. The framework's TypeScript integration extends to Server Actions with Zod validation, typed searchParams and params, and experimental typed environment variables.

For maximum strictness in a Next.js 15 project, the default tsconfig.json should be extended with noUncheckedIndexedAccess, exactOptionalPropertyTypes, noImplicitReturns, and verbatimModuleSyntax. The default skipLibCheck: true and moduleResolution: "bundler" should remain.

Migrating to strict mode without halting feature development

The proven strategy for large codebases is incremental migration — every success story from Bloomberg to Figma to Airbnb used gradual adoption, not a big-bang rewrite.

The recommended tool is typescript-strict-plugin from Allegro, with over 132,000 weekly npm downloads. The approach: enable strict: true globally, then add // @ts-strict-ignore at the top of every file that isn't yet compliant. New files are strict by default. Developers remove the ignore comment as they fix files, ensuring the codebase only moves toward strictness:

{
  "compilerOptions": {
    "strict": true,
    "plugins": [{ "name": "typescript-strict-plugin" }]
  }
}

Figma's migration of their 1,162-file frontend codebase is the most instructive case study. They started with an allowlist of already-compliant files, configured VS Code to show strict errors everywhere (even in non-compliant files), and treated dependency cycles as atomic units. Their largest cycle was 500+ files. Once more files were compliant than not, they switched from an allowlist to a denylist, making new files strict by default. The key insight from Figma's engineers: "The biggest benefit was the increased readability of our code. The parts where TypeScript had the most trouble inferring nullability were often the ones that were hard for humans to reason about — and benefited the most from refactoring."

For teams that prefer commit-level enforcement, ts-strictify runs as a pre-commit hook, checking only modified files. The @betterer/typescript package takes a ratcheting approach: it snapshots the current error count and fails CI if the count increases. When enabling strict sub-flags incrementally without tooling, the recommended order is: strictBindCallApply and alwaysStrict first (easy wins), then noImplicitAny (moderate effort), and strictNullChecks last (generates the most errors in large codebases, often thousands).

The evidence on strict mode and bugs is nuanced but compelling

The most-cited statistic in TypeScript advocacy is Airbnb's claim that 38% of production bugs could have been prevented by TypeScript, presented by Brie Bunge at JSConf Hawaii 2019 based on postmortem analysis. AWS later cited this figure in their SDK v3 documentation. The academic baseline comes from Gao et al.'s ICSE 2017 study "To Type or Not to Type," which found that ~15% of JavaScript bugs could be detected by TypeScript's type system — a figure the authors called a conservative underestimate since it only counted bugs that survived testing and code review.

A 2022 study by Bogner and Merkel analyzing 604 GitHub projects (16 million lines of code) found that TypeScript projects exhibited significantly better code quality (fewer code smells) and better understandability (lower cognitive complexity), but — crucially — bug proneness and resolution time were not significantly lower. The study's most relevant finding for strict mode advocates: reducing any usage was significantly correlated with better metrics across code quality, understandability, and bug resolution time (Spearman's rho 0.17–0.26). A 2025 study found that type-related errors fell from ~33% in JavaScript to 12.4% in TypeScript, though new bug categories like tooling/configuration issues emerged.

Bloomberg's adoption story provides the strongest enterprise evidence: over 50 million lines of code, 2,000+ engineers, strict mode enabled by default across their toolchain. Their telling metric: "More than 200 projects opted into TypeScript in the first year alone. Zero projects went back." The WisdomCircle startup reported a "significant reduction in error rates" after strict migration, with increased developer confidence in shipping.

The counterarguments deserve steelmanning. Eric Elliott argues that the 15% bug reduction is overstated when other quality measures (TDD, code review, design review) are already applied, noting that ~78% of bugs are specification errors that no type system can catch. DHH's famous objection — "Things that should be easy become hard, and things that are hard become any" — led to Turbo 8 dropping TypeScript entirely in September 2023, though this remains an outlier position.

The strict mode debate has a clear winner

The community has largely settled the strict mode debate, though pockets of resistance remain. TypeScript 6.0 will enable --strict by default — the TypeScript team's own framing says "for most new projects, --strict being off feels like it's usually an accident." Matt Pocock's position that the entire open-source TypeScript ecosystem is premised on strict mode — "all major libraries are written with strict mode in mind; opting out will cause random type bugs" — has become the mainstream consensus.

The "strict is not strict enough" camp argues for going further. Cyrille Tuzi notes that strict mode still allows explicit any types and advocates pairing strict: true with ESLint's @typescript-eslint/no-explicit-any rule. The TypeScript team experimented with a --strictAny flag but shelved it — Ryan Cavanaugh, TypeScript's lead developer, acknowledged wanting stricter any handling "around 50% of the time" but found the other 50% needed the escape hatch.

The AI dimension strengthens the strict-mode case decisively. GitHub's Octoverse 2025 explicitly ties TypeScript's contributor surge to AI-assisted coding. With 94% of LLM-generated compilation errors being type-check failures, strict TypeScript acts as a verification layer for AI-generated code. Teams with strong typing and clear patterns report the biggest reliability gains when using AI tools. As AI writes more code, the type system becomes less about catching human errors and more about constraining machine output — a fundamentally different value proposition that favors maximum strictness.

Conclusion

The argument that TypeScript's dominance is tied to strict type safety rests on converging evidence: the #1 pain point in JavaScript surveys is always missing types, the most-used language on GitHub is TypeScript, every major framework ships strict by default, AI coding tools rely on types as guardrails, and the TypeScript team itself is making strict the default. The practical implication is clear. Enable strict: true. Add noUncheckedIndexedAccess, exactOptionalPropertyTypes, and verbatimModuleSyntax. Use discriminated unions instead of enums, branded types for domain identifiers, Zod for runtime boundaries, and satisfies for configuration objects. Migrate incrementally with typescript-strict-plugin. The tooling, the ecosystem, and the data all point in one direction: strict TypeScript isn't a style preference — it's the baseline that earned TypeScript its win.