TypeScript 6.0 arrives at an unusual moment in the language’s history. The announcement lands while the successor architecture, Project Corsa, is already under active development. TypeScript 7, the native Go port, is progressing through its porting work, and the versioning carries an explicit signal: TypeScript 6.x is the last major release line that runs on Node.js. That context shapes how 6.0 should be read.
The release is still a genuine major version: accumulated breaking changes, adjusted defaults, and type system improvements that did not warrant their own minor release. But understanding where 6.0 sits in the timeline changes the evaluation. This is the JavaScript-hosted compiler at maturity, and the design decisions visible in the release have been building across the entire 5.x series.
What the 5.x Series Was Building Toward
The 5.x series stretched across roughly three years and built toward a coherent design point. TypeScript 5.0 shipped conformant decorators, retiring the experimental implementation that had accumulated compatibility debt since 2015. TypeScript 5.2 added using and await using from the Explicit Resource Management TC39 proposal, the first major resource-handling primitives JavaScript has natively. TypeScript 5.4 brought NoInfer<T>, a utility type giving callers fine-grained control over which generic positions trigger inference. TypeScript 5.5 shipped inferred type predicates and, more structurally significant, isolatedDeclarations.
isolatedDeclarations is worth understanding before looking at TypeScript 6.0, because it is one of the clearest examples of the team preparing the language for TypeScript 7. The option requires that all exported declarations carry explicit type annotations rather than relying on inference:
// violates isolatedDeclarations — return type requires cross-module inference
export function parseConfig(raw: string) {
return JSON.parse(raw) as Config;
}
// compliant — return type is locally derivable
export function parseConfig(raw: string): Config {
return JSON.parse(raw) as Config;
}The motivation is parallelization. If declaration files can be generated from each module’s type annotations alone, without resolving the full type graph across imports, build tools can parallelize declaration emit across the entire project. The Go-based TypeScript 7 compiler is designed to exploit this: declaration emit, type checking of independent modules, and program initialization can all run concurrently. The isolatedDeclarations constraint is the precondition that makes concurrent checking safe, and TypeScript 6.0 represents the release where codebases can treat this as a stable, recommended option rather than an experimental one.
Erasable Syntax as a Design Commitment
The broader pattern behind isolatedDeclarations is erasability: all TypeScript syntax should be safe to strip without changing runtime behavior. For most TypeScript code this has always been true, but the language has carried several constructs that violate it.
const enum expands to inline numbers at the call site, meaning a value change requires recompilation of every consuming file. Regular enum emits an IIFE that builds a bidirectional mapping object. namespace emits an IIFE wrapper. Parameter properties in class constructors emit assignment statements. All of these produce runtime JavaScript from what looks like type-level syntax.
TypeScript 5.0’s verbatimModuleSyntax option was an early enforcement mechanism for import erasability:
// ambiguous: the compiler must analyze whether this import has side effects
import { User } from './types';
// unambiguously erasable at any stripping stage
import type { User } from './types';Runtime environments that strip types, including Node.js’s native TypeScript support via --experimental-strip-types, Bun, and Deno, need imports to be unambiguously erasable. import type provides that guarantee. verbatimModuleSyntax enforces it at the compiler level.
TypeScript 6.0 continues this direction. The non-erasable constructs, enum, namespace, and parameter properties, have documented replacements: const objects with as const assertions cover most enum use cases, plain ES modules replace namespaces for code organization, and explicit property declarations replace parameter properties. TypeScript 6.0 does not remove these features, but the ecosystem trajectory increasingly favors the erasable variants for code that runs in type-stripping environments, and 6.0 is the release where the options and guidance around this are fully settled.
The TC39 type annotations proposal occupies the same design space. It aims to standardize a subset of TypeScript-compatible annotation syntax as official ECMAScript, ignorable by JavaScript engines without a compilation step. TypeScript’s erasable syntax work positions the language for whatever subset TC39 eventually standardizes, independent of the proposal’s pace through the process. The proposal has moved slowly, but the runtime-level type stripping that Node.js, Bun, and Deno have already shipped makes the question of TC39 standardization less urgent than it was a few years ago.
Default Options and the Housekeeping of a Major Version
Major versions collect breaking changes that accumulated too much friction for minor releases, and they recalibrate defaults to reflect current practice. The target compiler option defaulting to ES3 was appropriate in 2012; it has been indefensible as an implicit default for years. Modern JavaScript environments support ES2020 features at minimum. Output that avoids classes, arrow functions, template literals, and destructuring for compatibility with environments that no longer exist in production only makes the emit larger and harder to read. TypeScript 6.0 adjusts these defaults.
The removal of deprecated compiler options follows the same logic. Options deprecated across the 5.x series with documented replacement paths are removed rather than carried forward. This reduces the compiler’s configuration surface and eliminates maintenance of deprecated code paths that no current configuration should rely on.
For projects with explicit tsconfig.json settings, which includes any serious TypeScript codebase, these changes are invisible. target, lib, module, and moduleResolution should all be set explicitly. The projects affected by default changes are those relying on implicit behavior that was never authored, and the fix is a targeted tsconfig update, not a codebase migration.
Upgrading During the Transition Period
TypeScript 6.0’s position relative to TypeScript 7 matters for upgrade timing. The December 2025 progress update on Project Corsa described the Go port as a systematic translation of the existing compiler’s algorithms and data structures, designed to produce behaviorally identical output on identical inputs. TypeScript 6.x will receive updates during the transition period. TypeScript 7.0 ships as a native binary with no Node.js dependency for tsc or the language server.
Upgrading to 6.0 now is the right call. The migration from 6.x to TypeScript 7 will not require changes to TypeScript code itself; it is an infrastructure shift at the tooling level, not a type system change. The 6.x deprecation cycle is the mechanism that makes the eventual 7.0 migration manageable, and staying behind on 5.x means accumulating that migration surface unnecessarily.
For libraries published on npm, 6.0 is also a useful checkpoint to audit whether const enum usage, parameter properties, or namespace constructs can be replaced with erasable equivalents. TypeScript 7 will continue supporting these constructs. But codebases that avoid them are more portable across the type-stripping environments that Node.js, Bun, and Deno already represent. The shift toward erasability is not a TypeScript 7 requirement; it is the direction the ecosystem has been moving for several years, and TypeScript 6.0 is where the guidance and tooling around that shift are fully mature.