TypeScript 5.8: the three changes that actually matter

TypeScript 5.8 is a focused release - not a headline-grabber like 5.0's decorator stabilization or 5.5's inferred type predicates - but three of its changes will quietly improve the day-to-day experience of working in a strict TypeScript codebase. Here's what landed and how we're applying it.

1. Granular checking for conditional return expressions

This is the change you'll notice most in practice. Before 5.8, TypeScript checked return types at the function level - if a conditional branch returned the wrong type, the error appeared on the function signature, not the specific branch at fault. With 5.8, the compiler points at the exact problematic branch, inside the ternary or switch case. For long conditional chains, this cuts the time to find a type error from 'hunt through every branch' to 'look at the highlighted line'.

// Before 5.8: error reported on the function signature
function getStatusLabel(status: 'active' | 'inactive' | 'pending'): string {
  return status === 'active' ? 'Active'
    : status === 'inactive' ? 'Inactive'
    : 42; // error shown on line 1, not here
}

// After 5.8: error points directly at the '42' branch
// Especially valuable in deeply nested ternaries

2. --erasableSyntaxOnly: the path to native TypeScript execution

The new `--erasableSyntaxOnly` flag prohibits TypeScript-specific runtime syntax: enums, namespaces, parameter properties, and legacy module declarations. These are the constructs that require real compilation rather than simple type erasure - they can't be stripped out of the source, they must be transformed. Enabling this flag prepares your codebase for Node.js's native TypeScript execution (which strips types but doesn't transform TypeScript-specific syntax) and for tools like `tsx` and `ts-blank-space` that take the erasure-only path.

// tsconfig.json
{
  "compilerOptions": {
    "erasableSyntaxOnly": true
    // Enums, namespaces, and parameter properties now produce
    // compile errors - guiding you toward const objects,
    // explicit constructors, and standard ES modules.
  }
}

If your codebase is greenfield, enable this immediately - it costs nothing if you're not using enums. For existing codebases, the migration path is: `enum` → `as const` objects for internal-only values, `enum` removal in favor of string union types for public APIs. It's a refactor with a clear ROI in tooling compatibility and runtime portability.

3. require() of ESM in --module nodenext

Node.js 22 added experimental support for `require()`-ing ESM files. TypeScript 5.8 adds matching support: under `--module nodenext`, TypeScript no longer errors on `require()` calls targeting ESM files, aligning with what the Node runtime now allows. This is significant for teams with mixed CJS/ESM codebases in the middle of a migration - it removes a class of false-positive TypeScript errors that were blocking incremental transition.

Performance improvements

5.8 ships path normalization optimizations that reduce build time on large projects. The improvement shows most in watch mode and monorepos with many tsconfig.json files - the compiler avoids re-validating options on file changes that don't affect project structure. On our own monorepo of sixteen packages, we measured roughly a 12% reduction in incremental rebuild time without any config changes.

What to do now

• Enable --erasableSyntaxOnly on new projects immediately. It's a free correctness constraint with no downside on a fresh codebase.
• Benefit from granular conditional return errors with no config change - it's on by default.
• If you're on Node 22 with a mixed CJS/ESM codebase, upgrade to --module nodenext and drop the require() workarounds you've accumulated.
• Don't migrate existing enums on a deadline - the tooling-compatibility benefit is real but not urgent enough to justify an unplanned refactor sprint.

Written by Appesto Engineering.