TypeScript 7 is fast, but the Compiler API is gone. Here is what that breaks.

TypeScript 7 shipped on July 8, 2026. The compiler is rewritten in Go. Type-checking is 7x to 12x faster on real codebases. VS Code went from 36 seconds to 5 seconds on tsc --noEmit. The numbers are real.

The catch: the npm typescript@7 package exports version and versionMajorMinor. That’s it. The entire Compiler API is gone. Any tool that does import * as ts from "typescript" breaks.

$ node -e "const ts = require('typescript'); console.log(Object.keys(ts))"
[ 'version', 'versionMajorMinor' ]

This post covers what TS7 actually changed, what breaks in a real project, and the workaround that lets you use the fast compiler while keeping your toolchain working.

What TS7 is

TypeScript 7 (“Project Corsa”) is a complete Go rewrite of the compiler. The Go port reproduced identical type-checking behavior from the JavaScript codebase (“Strada”). Microsoft chose Go over Rust because Rust’s ownership model prohibits cyclic data structures, and the TypeScript AST is full of them. A Go port took roughly a year.

The tsgo binary is the real compiler. It does not expose a JavaScript API. The npm typescript@7 package is a transition shim: it shells out to tsgo for tsc commands and provides nothing programmatic.

A new programmatic API is planned for TypeScript 7.1, which Microsoft describes as “at least several months away” (Announcing TypeScript 7.0). Until then, the Compiler API does not exist.

What changed in tsconfig

TypeScript 6.0 deprecated several options. TypeScript 7.0 makes them hard errors. If you skipped 6.0, the upgrade catches you off guard.

New defaults:

• rootDir now defaults to ./. Projects with tsconfig.json outside src/ need an explicit rootDir.
• types now defaults to []. Projects that silently depended on ambient @types packages must list them explicitly.
• stableTypeOrdering is true by default and cannot be turned off.

Hard errors (were warnings in 6.0):

• target: es5 is no longer supported.
• baseUrl is no longer supported. Use paths relative to the project root.
• moduleResolution: node/node10 is no longer supported. Use nodenext or bundler.
• module: amd, umd, systemjs, none is no longer supported. Use esnext or preserve.
• esModuleInterop and allowSyntheticDefaultImports cannot be false.
• alwaysStrict is assumed true.

The ts5to6 tool automates the baseUrl to paths migration, explicit rootDir setting, and assert to with attribute updates.

The VS Code team reported that the rootDir and types changes were the most surprising. Both are mitigated by explicit configuration.

The Compiler API gap

This is the breaking change that matters most for tooling.

The Strada API (import * as ts from "typescript") gave you ts.SyntaxKind, ts.createSourceFile, ts.isClassDeclaration, ts.parseJsonConfigFileContent, and hundreds of other exports. Tools built parsers, linters, code generators, and language services on top of it. In TS7, all of these are undefined.

Visual Studio Magazine reported the same gap: the stable programmatic API is not expected until TypeScript 7.1, which leaves typescript-eslint, ts-morph, and custom transformers without a compiler to target in 7.0.

Tools that break

The typescript-eslint maintainer Bradzacher wrote: “For now there is nothing we can do to support tsgo / TSv7. As mentioned in the blog post and highlighted above, there is currently no stable JS API.”

Framework template type-checkers

Vue, Svelte, Astro, and MDX use Volar or similar tools that embed TypeScript’s compiler into their own language service. They type-check the portions of your application that live outside .ts files: component templates, style bindings, slot types.

Without the Compiler API, they cannot type-check templates against the native compiler. The TechTimes summary put it clearly: “Vue, Svelte, and Astro developers will not see a broken build, but they will not get the 8-12x speedup in editor feedback either.”

The Astro team is tracking compatibility. Framework template type-checkers cannot adopt TS7 until the new API ships in 7.1.

What I hit in practice

I maintain three repos that use TypeScript with strict peer dependency settings and Renovate for dependency management. TypeScript 7 broke all three, in different ways.

bscraper: Dagger SDK crash

The Dagger CI module’s ci/package.json had typescript: "6.0.3". Renovate bumped it to 7.0.2. The Dagger Engine container loaded TS7, and the SDK’s bundled core.js crashed at module init:

TypeError: Cannot read properties of undefined (reading 'ClassDeclaration')
    at /src/ci/sdk/core.js:102162:19

The crash is at a static lookup table built at module load:

// Dagger SDK core.js (simplified)
[ts2.SyntaxKind.ClassDeclaration]: ts2.isClassDeclaration,

When typescript@7 is the resolved version, ts2.SyntaxKind is undefined. The bracket access throws before any user code runs. The @dagger.io/dagger@0.21.7 SDK has typescript: "^6.0.3" as a direct dependency, not a peer. It uses the Compiler API to parse and transform user-written Dagger module ASTs.

deepblock: typescript-eslint peer

The typescript-eslint@8.63.0 package peers typescript >=4.8.4 <6.1.0. Under strictPeerDependencies: true in pnpm-workspace.yaml, TS7 fails to install:

✕ unmet peer typescript
  Installed: 7.0.2
  Wanted:
    ">=4.8.4 <6.1.0":
      typescript-eslint@8.63.0

Renovate cannot bump typescript major without breaking the linter. The fix is the same as bscraper: a Renovate hold on typescript major.

bscraper and deepblock: the coexistence question

Both projects already use TS7 for compilation via @typescript/native-preview (the tsgo binary). The Dagger module and the linter need TS6. The two TypeScripts live in separate execution environments:

• The project compiles with tsgo (TS7). Fast.
• The Dagger module installs its own typescript@6 in its container. The SDK uses the Compiler API.
• typescript-eslint imports from the TS6 alias. Linting works.

The hold preserves both: TS7 for the project, TS6 for the tools that need the API.

The side-by-side workaround

Microsoft’s official recommendation is to install TS6 alongside TS7:

// package.json
{
  "devDependencies": {
    "typescript": "npm:@typescript/typescript6@^6.0.0",
    "typescript-native": "npm:@typescript/native-preview@^7.0.0"
  }
}

The @typescript/typescript6 package provides a tsc6 binary and re-exports the Strada API. Tooling that imports from typescript gets TS6. The fast tsgo binary is available as typescript-native.

The alias has real package-manager quirks the announcement glossed over. In microsoft/typescript-go#4567 (filed the day 7.0 shipped), TypeScript team lead Ryan Cavanaugh explained that npm picks bin winners by lexical sort rather than dependency depth, so the alias names matter, and that yarn and pnpm resolve the conflict differently. The split still holds: TS7 for tsc and CI type-check jobs now, the TS6 alias for linting and codegen, and a full switch-over gated on the 7.1 API.

What is blocked until TS 7.1

The Dagger 1.0 milestone has 10 open issues and 1 closed. No beta releases exist. The latest release is v0.21.7 (2026-06-17), shipped before TS7.

Practical advice

1. For pure compilation speed: Adopt TS7 now. tsc --noEmit and build commands are dramatically faster.
2. For linting: Stay on the TS6 alias until typescript-eslint ships TS7 support.
3. For Dagger CI: Hold typescript major in the module’s package.json. The SDK needs the Compiler API.
4. For Vue/Svelte/Astro: Stay on TS6 for editor support. Builds can use TS7 in parallel.
5. For tsconfig: Audit before upgrading. The rootDir, types, and baseUrl changes catch teams off guard.
6. For Renovate: Hold typescript major in any package that depends on tools needing the Compiler API. Use matchUpdateTypes: ["major"] with "enabled": false.

References

• Announcing TypeScript 7.0 - the Go rewrite, side-by-side setup, and what changed
• VS Code: Iterating faster with TypeScript 7 - real-world migration experience and performance numbers
• TypeScript 7.0 RC Moves Microsoft’s Go Rewrite Into the Mainline Compiler (Visual Studio Magazine) - the 7.1 programmatic API gap and tool compatibility
• tsc incorrectly points to v6 rather than v7 (microsoft/typescript-go#4567) - TypeScript team lead Ryan Cavanaugh on the side-by-side alias bin-conflict quirks across npm/yarn/pnpm
• typescript-eslint #10940: Use TS 7 for type information - the tracking issue, labeled “blocked by external API”
• TypeScript 7 Now Stable: Not for Vue or Svelte Yet - framework template type-checker impact
• Astro TypeScript Native compatibility tracking - Astro’s path to TS7
• Reducing Renovate’s blast radius - the Renovate hold pattern for dependency conflicts