TypeScript 7.0 RC: What

TypeScript 7.0 dropped its Release Candidate this week, and the changelog is not a minor version bump dressed up in a major version costume. This is a genuine architectural shift in how TypeScript handles type resolution, module interop, and strictness defaults — and it will break things in your codebase if you upgrade without reading the notes first.

I've been tracking the RC closely. This article is a direct comparison: TypeScript 6.x behavior vs. TypeScript 7.0 RC behavior, across the changes that matter most for production teams. I'll show you real code, real errors, and give you a straight answer on whether you should upgrade now or wait.

---

The JavaScript Ecosystem Context: Why This Release Matters Now

The broader ecosystem has been moving hard toward stricter, faster tooling. We saw Fable convert Pylint to Rust this week, trimming lint times dramatically. The TypeScript team is pushing in the same direction — TypeScript 7.0's native Go-based compiler (tsgo) is the headline performance story, promising 10x faster build times on large monorepos. But performance is the easy sell. The harder conversation is about what breaks.

Let's get into it.

---

What Changed: The Six Things You Actually Need to Know

1. The Native Go Compiler (tsgo) Is Now the Default Path

TypeScript 7.0 ships with a new compiler written in Go, developed under the internal project name "Corsa." The original JavaScript-based tsc still exists and still works, but the RC strongly positions tsgo as the forward path.

What this means in practice: Your existing tsconfig.json is compatible. Your existing build pipeline is not necessarily compatible. Tools that shell out to tsc directly — certain webpack plugins, ts-jest configurations, older versions of ts-node — may need updates before tsgo works cleanly in your CI.

The performance claims are real. On a 400k-line monorepo, cold build times drop from ~45 seconds to under 5 seconds in internal benchmarks. For teams where TypeScript compilation is a bottleneck, this alone is worth the upgrade path investment.

2. isolatedModules Is Now true By Default

This is the breaking change that will hit the most teams without warning.

TypeScript 6.x behavior: isolatedModules defaulted to false. You could use const enum, namespace merging across files, and ambient module augmentation freely without any compile flags.

TypeScript 7.0 RC behavior: isolatedModules is true by default for all new and existing tsconfig.json files that don't explicitly set it.

// This worked fine in TypeScript 6.x with isolatedModules: false
const enum Direction {
  Up,
  Down,
  Left,
  Right
}

function move(dir: Direction) {
  return dir === Direction.Up ? "going up" : "other";
}

In TypeScript 7.0, this emits:

error TS1748: Cannot access ambient const enums when 'isolatedModules' is enabled.

The migration path: Replace const enum with regular enum or a plain object with as const:

// TypeScript 7.0 compatible
const Direction = {
  Up: 0,
  Down: 1,
  Left: 2,
  Right: 3,
} as const;

type Direction = typeof Direction[keyof typeof Direction];

function move(dir: Direction) {
  return dir === Direction.Up ? "going up" : "other";
}

This is not just a stylistic change. const enum inlining was always a footgun in environments where files are compiled independently (esbuild, SWC, Babel with @babel/plugin-transform-typescript). TypeScript 7.0 is forcing the ecosystem to a pattern that's been the practical recommendation for years. It's the right call. It will still cause breakage.

3. Strict Mode Defaults Have Expanded

TypeScript 7.0 adds two new checks to the strict umbrella flag:

• strictBuiltinIteratorReturn: The return type of built-in iterators (like Array.prototype[Symbol.iterator]()) is now typed as IteratorResult<T, undefined> rather than IteratorResult<T, any>. Code that was implicitly relying on any as the return type of a done iterator will now surface type errors.

• noUncheckedSideEffectImports: Side-effect imports (e.g., import './polyfill') are now checked to ensure the module actually exists and resolves. Previously, TypeScript silently allowed unresolvable side-effect imports.

// TypeScript 6.x: no error, even if this file doesn't exist
import './does-not-exist';

// TypeScript 7.0 with noUncheckedSideEffectImports (now part of strict):
// error TS2307: Cannot find module './does-not-exist' or its corresponding type declarations.

For teams with a clean codebase, these are welcome guardrails. For teams with legacy polyfill imports, barrel files with side effects, or third-party imports that lack proper type declarations, expect a non-trivial error count on first compile.

4. Module Resolution: node16 and bundler Behavior Tightened

TypeScript 7.0 tightens how it handles exports field resolution in package.json under both node16 and bundler module resolution modes.

The practical impact: Packages that have an exports field in package.json but incomplete condition mappings (missing types, missing default) now produce errors where TypeScript 6.x would silently fall back to the root index.d.ts.

// package.json with incomplete exports - caused silent fallback in TS 6.x
{
  "exports": {
    ".": {
      "import": "./dist/index.mjs",
      "require": "./dist/index.cjs"
    }
  }
}

In TypeScript 7.0 with moduleResolution: "bundler":

error TS2307: Cannot find module 'some-package' or its corresponding type declarations.

The fix is on the package maintainer's side — they need to add a types condition. But in the meantime, you can work around it:

// tsconfig.json workaround
{
  "compilerOptions": {
    "moduleResolution": "bundler",
    "paths": {
      "some-package": ["./node_modules/some-package/dist/index.d.ts"]
    }
  }
}

Not pretty, but it unblocks you while waiting for upstream fixes.

5. The erasableSyntaxOnly Flag

TypeScript 7.0 introduces --erasableSyntaxOnly, a new compiler flag that restricts your TypeScript to only syntax that can be removed (erased) to produce valid JavaScript — no transformations, no emit-time code generation.

This is TypeScript leaning into the TC39 Type Annotations proposal and the broader trend of runtimes (Node.js 23+, Bun, Deno) supporting TypeScript directly via type stripping.

What's disallowed under erasableSyntaxOnly:

• enum (both regular and const — requires runtime code generation)
• namespace with values (not just types)
• Parameter properties in constructors (constructor(private name: string))

// NOT allowed with erasableSyntaxOnly: true
class User {
  constructor(private name: string, public age: number) {}
}

// Allowed with erasableSyntaxOnly: true
class User {
  private name: string;
  public age: number;

  constructor(name: string, age: number) {
    this.name = name;
    this.age = age;
  }
}

This flag is opt-in in the RC. It's not part of strict. But if your team is targeting Node.js 23+ with --experimental-strip-types or running TypeScript in Bun/Deno, you should be enabling it now to stay aligned with where the runtime ecosystem is heading.

6. Declaration Emit Changes for .d.ts Files

TypeScript 7.0 changes how certain complex mapped types are serialized in .d.ts output. In some cases, previously-simplified type representations are now emitted verbatim, resulting in larger .d.ts files and occasionally different assignability behavior for consumers of your library.

This is the most esoteric breaking change, and it primarily affects library authors rather than application developers. If you publish a TypeScript library, run tsc --declaration against the RC and diff your .d.ts output before shipping.

---

Direct Comparison: TypeScript 6.x vs TypeScript 7.0 RC

Dimension	TypeScript 6.x	TypeScript 7.0 RC
Compiler	JavaScript (tsc)	Go (tsgo) — 10x faster
isolatedModules default	false	true
const enum support	Full support	Errors by default
noUncheckedSideEffectImports	Not in strict	Now part of strict
strictBuiltinIteratorReturn	Not in strict	Now part of strict
exports field resolution	Silent fallback	Strict, errors on incomplete maps
erasableSyntaxOnly	Not available	Available (opt-in)
Parameter properties	Always supported	Blocked by erasableSyntaxOnly
Runtime strip compatibility	Limited	First-class via erasableSyntaxOnly

---

The Verdict: Upgrade Now or Wait?

Upgrade now if:

• You're starting a new project — use TypeScript 7.0 from day one, set erasableSyntaxOnly: true, and build clean
• Your existing codebase already has isolatedModules: true and strict: true — your delta is probably small
• You're running a monorepo where TypeScript build times are a real bottleneck — the tsgo performance gains are not marketing, they're structural
• You're targeting modern runtimes (Node.js 23+, Bun, Deno) that support type stripping natively

Wait if:

• You have significant const enum usage spread across a large codebase — the migration is mechanical but tedious and should be a planned sprint, not a surprise
• You depend on packages with incomplete exports fields in package.json — check your dependency tree first with npm ls and identify which packages will break
• You use ts-jest, ts-node, or older webpack TypeScript plugins that haven't shipped tsgo compatibility yet — check their release notes before upgrading

The honest take: TypeScript 7.0's breaking changes are almost all in service of correctness and ecosystem alignment. The isolatedModules default change should have happened three years ago. noUncheckedSideEffectImports catches real bugs. erasableSyntaxOnly is the right architectural direction for a world where runtimes are handling TypeScript directly.

The pain is real but it's one-time. The patterns TypeScript 7.0 enforces are the patterns you should have been using anyway.

---

Migration Checklist

Before running npm install typescript@rc on an existing project:

1. Audit const enum usage: grep -r "const enum" src/ — every hit needs remediation
2. Check side-effect imports: grep -r "^import '" src/ | grep -v "from" — verify each resolves
3. Run tsc --noEmit with isolatedModules: true first — fix errors before touching anything else
4. Test your build toolchain: Verify ts-jest, webpack ts-loader, or whatever you use has tsgo support in its latest release
5. If you're a library author: Diff your .d.ts output and consider a minor version bump when you ship against 7.0

The official TypeScript 7.0 RC announcement and the TypeScript GitHub repository are your authoritative sources for the full changelog and known issues as the RC stabilizes toward GA.

This is a healthy major version. It's not TypeScript being aggressive — it's TypeScript finishing the job on defaults that should have been stricter from the start. Plan your migration, run the checklist, and get on 7.0 before the ecosystem moves on without you.