TypeScript 5.8: What Is Worth Adopting First

The Short Adoption Matrix

• Adopt immediately: the performance improvements (free), the narrowing improvements on discriminated unions (fewer as casts), and the --erasableSyntaxOnly flag if your toolchain splits type-stripping from type-checking.
• Adopt on a project basis: --module node20 + --moduleResolution node20 combinations for Node LTS alignment.
• Wait: niche additions that apply to a small fraction of codebases. Upgrading primarily for them is rarely worth it.

Narrowing Wins in Practice

TypeScript's control-flow analysis continues to improve in 5.8, particularly for discriminated unions with nested objects. Patterns that used to require a cast now narrow cleanly:

type Result =
  | { ok: true; data: { id: string; name: string } }
  | { ok: false; error: { code: number; message: string } };

function handle(r: Result) {
  if (r.ok && r.data.id.startsWith('u_')) {
    // r.data is narrowed; no cast needed
    return r.data.name;
  }
  if (!r.ok) {
    return `${r.error.code}: ${r.error.message}`;
  }
  return null;
}

The practical impact is fewer as casts in domain code, which in turn means a smaller audit surface for unsafe type assertions. For teams that use @typescript-eslint/no-unnecessary-type-assertion, the lint will clean up on first run.

Erasable Syntax Only

The --erasableSyntaxOnly flag rejects TypeScript features that cannot be erased to plain JavaScript. Namespaces with runtime behaviour, enums, parameter properties, and a few others. This matters for teams using tools like tsx, ts-node --esm, or Node's own experimental stripping, where only erasable syntax is supported. Turning the flag on prevents accidental reintroduction of features that break type-stripping toolchains.

// tsconfig.json
{
  "compilerOptions": {
    "erasableSyntaxOnly": true,
    // enums, namespaces, parameter properties now produce errors
  }
}

Module Resolution Alignment

The node20 module and moduleResolution settings align TypeScript's understanding of module resolution with Node.js LTS behaviour. Import assertions, --experimental-require-module semantics, and other Node-specific details. If your deployment target is Node 20 or 22 LTS, adopt these; the alternative is subtle runtime surprises that the compiler could have caught.

Performance. Invisible but Worth the Jump

Every point release tightens the type checker's inner loops. Compared with 5.5, most medium codebases see 5–12% faster incremental checks on 5.8. That is not glamorous, but on large monorepos it is the difference between a pleasant PR loop and a friction point. For teams measuring build performance, the upgrade often pays for itself in a quarter.

The Migration Reality

TypeScript minor releases occasionally tighten inference in ways that surface latent issues. 5.8 is relatively calm on that front. The majority of codebases on 5.5+ compile clean. Expect a small number of "narrower than before" errors in utility types and in code that relied on structural-typing edge cases; the fixes are almost always local.

The Adoption Priority

• Upgrade the compiler in a single PR; fix any surfaced errors before enabling anything new.
• Turn on erasableSyntaxOnly if your runtime toolchain requires it.
• Move module/moduleResolution to node20 on Node LTS projects.
• Re-run @typescript-eslint/no-unnecessary-type-assertion to reap the narrowing improvements.
• Skip the niche features unless they solve a problem you already have.