TypeScript 5.7 shipped on November 22nd, and buried in the release notes—between the new --target es2024 flag and path rewriting improvements—is a fix that’s bugged me for years. The compiler now detects when you access an uninitialized variable inside a nested function.

If that sounds minor, you haven’t hit this one yet. I have. More than once.

The Problem That Was Always There #

Here’s the setup. You declare a variable, intend to assign it later; then you reference it inside a callback or inner function before the assignment actually runs:

let config: Config;

function loadConfig() {
  // This runs later, maybe async
  config = fetchConfigFromDisk();
}

function useConfig() {
  // Pre-5.7: TypeScript assumes config is assigned. No error.
  // 5.7: Error --- 'config' is used before being assigned.
  console.log(config.timeout);
}

Before 5.7, TypeScript took an “optimistic” view of variable initialization, leaning on the assumption that access inside a nested function landed after the assignment. The reasoning made some sense: the compiler couldn’t easily determine the runtime execution order of loadConfig() versus useConfig(). So it assumed the best case. The variable probably got initialized by the time the inner function ran.

Probably. That word caused a lot of production bugs—more than I care to count.

Why It Took So Long #

Control flow analysis—the system TypeScript uses to narrow types and track variable state—operates on a per-function basis. When you step into a nested function boundary, the analysis effectively resets its assumptions about variables from the outer scope. TypeScript knew the variable existed. It knew the type. It just never tracked assignment across that function boundary.

No oversight here; a deliberate trade-off explains the gap. Tracking initialization state across nested function boundaries is genuinely hard. The nested function runs synchronously (outer variable state: known) or asynchronously (outer state: anything). It runs once or a thousand times. The call happens conditionally or unconditionally.

The TypeScript team acknowledged this gap years ago and logged it. What finally closed it: a community contribution from a GitHub user named Zzzen. I appreciate when the release notes give credit where it’s due—this kind of compiler work is detailed and thankless.

How the New Check Works #

The 5.7 compiler now tracks a “definitely assigned” state for variables that persists across nested function boundaries. If a variable gets declared but not assigned before a nested function reads it, you get an error at the read site.

let name: string;

// Error: Variable 'name' is used before being assigned.
const greet = () => console.log(`Hello, ${name}`);

name = "Felipe";
greet(); // This would work at runtime, but TS flags the definition site.

The check leans conservative, in the right direction—flagging cases where the variable could go uninitialized, even if at runtime the call order works out fine. That’s the right trade-off for a type checker: false positives annoy you; false negatives become bugs.

If you know the assignment happens before the call, the definite assignment assertion (let name!: string;) opts you out. Same escape hatch as before; now you’re making an explicit promise to the compiler rather than silently relying on its optimism.

–target es2024 #

The other headline feature: --target es2024 and the corresponding --lib es2024. ECMAScript 2024 got ratified in June; TypeScript now emits code targeting that spec level without downlevel transforms for features like:

• SharedArrayBuffer and Atomics.waitAsync
• Object.groupBy and Map.groupBy
• Promise.withResolvers
• ArrayBuffer.prototype.resize and ArrayBuffer.prototype.transfer

Object.groupBy topped my personal wait list. Every project I worked on had some variation of a groupBy utility function—sometimes from lodash, sometimes hand-rolled, sometimes both in the same codebase (don’t ask). Having it in the standard library with proper typing: long overdue.

const grouped = Object.groupBy(users, (user) => user.role);
// grouped: Partial<Record<string, User[]>>

The return type resolves to Partial<Record<K, T[]>> rather than Record<K, T[]>. That Partial matters. Not every key you’d expect from the union type K appears in the result. TypeScript gets this right where a naive typing would lie to you.

Path Rewriting in Declaration Output #

This one’s less flashy but matters for library authors. TypeScript 5.7 rewrites relative import paths in .d.ts output files when you set the --rewriteRelativeImportExtensions flag. If your source uses .ts extensions in imports (more and more common with ESM-first projects and Bun), the declaration output correctly maps those to .js or .d.ts extensions.

Before this, library authors targeting ESM had to either avoid .ts extensions in imports—fighting the tooling—or post-process their declaration files (fighting the build system). Neither option worked well.

I run Bun as my primary runtime for side projects, and the import extension situation generated one of those paper-cut annoyances that compounds over time. This helps.

Better Error Reporting #

TypeScript 5.7 also improved how it reports errors for --isolatedDeclarations. Instead of pointing at the entire declaration and saying “this needs an explicit type annotation,” it now identifies the specific part of the declaration that requires annotation. Smaller thing; anyone who’s stared at a wall of red squiggles in a large codebase knows how much diagnostic precision matters.

The compiler also now validates that JSON imports match their resolved types more strictly, catching cases where a *.json import’s shape drifts from what the code expects. This caused subtle runtime failures—the JSON file changes, the types don’t update, TypeScript shrugged.

The Pattern I Keep Seeing #

Every TypeScript release follows a similar arc. One or two headline features get the attention (this time: the init check and es2024 target). A handful of smaller improvements matter more to specific workflows (path rewriting for library authors, better JSON validation). And the overall trajectory moves toward catching more classes of bugs at compile time rather than at 3 AM when your monitoring alerts go off.

The uninitialized variable check shows TypeScript’s maturity as a project. Early TypeScript added types to JavaScript. Modern TypeScript closes gaps in what those types prove about your program’s behavior. The nested function init check isn’t a new feature—it’s the removal of a known blind spot.

What I appreciate most about this release: the restraint. No dramatic new syntax. No paradigm shifts. Just the compiler getting smarter about catching real bugs, with a community contributor closing a gap the core team documented but never prioritized.

That’s what good infrastructure looks like: boring improvements that prevent exciting failures.