TypeScript 7.0: 10x Faster Builds, No Stable Programmatic API, and What Actually Breaks

What Actually Shipped

TypeScript 7.0 is a complete rewrite of the compiler and language service in Go. Not a partial port, not a JIT trick — the Go binary ships as the new tsc. The old compiler was TypeScript running on Node.js, compiled to JavaScript, executed in a single-threaded V8 context. That design worked well for a decade and then started showing its limits as codebases hit hundreds of thousands of lines.

The headline numbers hold up. Microsoft's own VSCode codebase went from **125.7 seconds to 10.6 seconds** for a full type-check — an 11.9x improvement on a real-world repo of around 900,000 lines. Across typical projects, the speedup lands between 8x and 12x depending on your dependency graph and file count.

The architectural reason: the Go port uses goroutines to parallelize file parsing and type resolution. The old Node.js compiler couldn't saturate a modern CPU. The new binary can.

One important nuance: this speedup applies to tsc specifically. If you're using Vite, esbuild, or SWC for local dev, those tools do their own transpilation and bypass tsc entirely — your hot reload time doesn't change. What changes is the tsc --noEmit step in your CI pipeline or your pre-merge typecheck gate. That's often the part eating 2-3 minutes per PR, and that's where the win is real.

The Part That's Actually Breaking Things: No Stable Programmatic API

Three weeks in, this is where teams are getting surprised.

TypeScript 7.0 ships **without a stable programmatic API**. The import * as ts from 'typescript' surface — ts.createProgram(), ts.createLanguageService(), ts.TypeChecker, all of it — is explicitly marked unstable in this release. The team is locking it down for TypeScript 7.1, which lands roughly October 2026.

What this looks like in practice:

// This pattern is fragile in TypeScript 7.0
import * as ts from 'typescript';

const program = ts.createProgram({
  rootNames: ['./src/index.ts'],
  options: { strict: true },
});

// Works today, may silently break in a 7.0 patch release
const checker = program.getTypeChecker();

Anything that invokes tsc as a CLI subprocess? Fine. Anything that imports typescript as a library and calls into the compiler API? You're on unstable ground until 7.1.

Packages currently pinned to TypeScript 6 because of this:

• ts-jest — Jest's TypeScript transformer

• ts-node — on-the-fly TypeScript execution

• Custom webpack or Vite transformer plugins that use ts.TransformerFactory

• ESLint plugins that walk ts.TypeChecker for type-aware lint rules

If any of these are in your package.json, staying on typescript@^6 is the right call for now. Don't let a dependency on an unstable API turn a CI speedup into a broken test suite.

Config Changes That Blow Up Silently

Beyond the API situation, there are configuration-level changes that cause compile failures on upgrade.

**Strict mode is now the default.** TypeScript 7.0 ships with strict: true if you don't set it explicitly in tsconfig.json. Codebases that relied on the old loose defaults will suddenly see errors they've never encountered — implicit any, possibly-undefined property access, uninitialized class properties. The fix is to add "strict": true to your tsconfig.json before upgrading so the new default is a no-op, or set "strict": false explicitly if you're not ready to deal with the backlog.

**All TypeScript 6.x deprecation warnings are now hard errors.** Anything that generated a deprecation warning in 6.x now fails the build outright. Common culprits: module: CommonJS without a compatible moduleResolution, legacy decorator syntax mixed with the new proposal, and older @types packages that leaned on deprecated globals.

**Vue and Svelte SFCs are currently broken.** Both frameworks' typed template systems use the compiler's programmatic API under the hood for template type-checking. Until the Vue language tools and Svelte's TypeScript plugin are updated for the 7.1 API surface, you'll get spurious errors in single-file components that have nothing to do with your actual code.

Should You Upgrade Now?

Here's the practical call tree. Both blocking conditions lead to the same answer.

If you're on a plain TypeScript project — Node.js backend, React with Vite or Next.js, no custom compiler plugins — the upgrade is straightforward:

npm install typescript@7 --save-dev
npx tsc --noEmit
# Fix strict-mode errors as needed

Most errors you'll see are implicit any on function parameters, possibly-undefined property accesses, and return types that were being inferred as any under the old defaults. On a medium-sized codebase, plan for an afternoon. The CI payoff — a 10x cut on your typecheck step — compounds across every PR your team ships for the rest of the year.

What 7.1 Unlocks

TypeScript 7.1 is the release the broader ecosystem is actually waiting for:

• **Stable programmatic API** — ts.createProgram() and the language service surface get locked and documented

• **ts-jest and ts-node** — both teams have open issues explicitly tracking the 7.1 API stabilization before updating their peer dependency ranges

• **Vue and Svelte tooling** — active development underway from both maintainer teams, unblocked once the API is stable

• **Timeline** — approximately October 2026, based on the TypeScript team's consistent cadence of three to four months between major point releases

The Go port is a permanent architectural win. The disruption is temporary and concentrated in a specific, well-defined surface area. If you're not using the programmatic API and not on Vue or Svelte, upgrade now and take the speed.

For teams that can't move yet: add "strict": true to your tsconfig.json today. When you finally upgrade, the new default won't ambush you with hundreds of errors you've never seen before.