TypeScript Is Rewriting in Go: What Developers Need to Know in 2026

Two things are happening to TypeScript simultaneously. One affects you right now. One changes the tool you've been using your entire career.

TypeScript 6.0 is stable — shipped mid-2026 with new defaults that break builds silently if your tsconfig.json relies on implicit values. If you haven't audited your config, your CI might already be affected on the next dependency update.

TypeScript 7.0 is a full rewrite in Go — led by Anders Hejlsberg, the Go-based compiler is in active development and ships with ~8x faster project load times. It's not production-ready yet, but it's real and moving fast.

Here's everything you need to know and act on.

TypeScript 6.0: The Breaking Default Changes

TS 6.0 marks the end of the old defaults that were set when TypeScript targeted Internet Explorer. The team finally moved the floor to match where JavaScript actually runs today.

These defaults are correct for modern apps. The problem is any tsconfig.json that didn't explicitly set these options is now silently getting different behavior than before.

What breaks in practice

CommonJS libraries: if you publish an npm package without an explicit module setting and your toolchain expects CJS output, you now get ESM output. Any consumer doing require('your-package') throws.

Old Node.js targets: ES2023 output uses Array.prototype.findLast, Object.hasOwn, structured cloning. If you target Node 16 or earlier, set target explicitly.

Class field initialization: useDefineForClassFields: true aligns TypeScript with TC39 semantics. Angular users and anyone using decorators — check your class fields carefully.

moduleResolution: "node" consumers: the bundler resolution strategy doesn't honor the exports map the same way. If you have packages with complex exports fields, test thoroughly.

Migration Guide: Lock Down Your Config Before Upgrading

The safest path is explicit configs before upgrading. Don't let TS 6.0 infer new defaults from a tsconfig written against old ones.

Audit command

# See what TS version you're on
npx tsc --version
 
# Check what tsconfig files exist
find . -name "tsconfig*.json" -not -path "*/node_modules/*"
 
# Find missing explicit target/module settings
grep -L '"target"' $(find . -name "tsconfig*.json" -not -path "*/node_modules/*")

Preserve TS 5.x behavior (safe, no breakage)

If you need to upgrade TypeScript without touching your output:

{
  "compilerOptions": {
    "target": "ES2017",
    "module": "CommonJS",
    "moduleResolution": "node",
    "useDefineForClassFields": false,
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "outDir": "./dist"
  }
}

Modern app config (Next.js, Vite, modern bundlers)

{
  "compilerOptions": {
    "target": "ES2023",
    "module": "ESNext",
    "moduleResolution": "bundler",
    "lib": ["ES2025", "DOM", "DOM.Iterable"],
    "allowImportingTsExtensions": true,
    "noEmit": true,
    "strict": true,
    "verbatimModuleSyntax": true,
    "isolatedModules": true
  }
}

Note lib: ["ES2025"] — TS 6.0 ships ES2025 type definitions. lib controls what type definitions are available, target controls what syntax the compiler emits. They're independent.

Library authors

{
  "compilerOptions": {
    "target": "ES2020",
    "module": "NodeNext",
    "moduleResolution": "NodeNext",
    "declaration": true,
    "declarationMap": true,
    "sourceMap": true,
    "strict": true,
    "outDir": "./dist"
  }
}

NodeNext is the correct choice for packages supporting both CJS and ESM via dual package exports. Don't use ESNext + bundler resolution in a published library — consumers without bundlers will break.

Temporal API Types: Finally in Core

One genuinely useful addition in TS 6.0: Temporal API types are now in the standard lib when you use lib: ["ES2025"].

// No more @js-temporal/polyfill types — it's in the stdlib
 
const now = Temporal.Now.plainDateTimeISO()
console.log(now.toString())
// "2026-09-25T14:32:10.123456789"
 
// Timezone-aware instant
const meeting = Temporal.ZonedDateTime.from({
  timeZone: 'America/New_York',
  year: 2026, month: 9, day: 30, hour: 10,
})
 
// Duration arithmetic that actually works
const deadline = meeting.add(Temporal.Duration.from({ weeks: 2 }))
 
// Compare without Date.getTime() hacks
const isUpcoming = Temporal.ZonedDateTime.compare(
  deadline,
  Temporal.Now.zonedDateTimeISO('America/New_York')
) > 0

If you've been using @js-temporal/polyfill and its type definitions, you can drop the types package. Keep the runtime polyfill until your target environments ship native Temporal (V8 and SpiderMonkey are ahead of Safari here).

TypeScript 7.0: The Go Rewrite

This is the bigger story — not for today, but for the next three years.

Microsoft is rewriting the TypeScript compiler in Go. Anders Hejlsberg is leading the project. A native preview is shipping inside Visual Studio 2026, and the project is moving quickly.

The numbers: ~8x faster project load times. For large monorepos where tsc currently takes 30-60 seconds, you're looking at 4-8 second cold builds. For teams spending 2 minutes on type checking in CI, that becomes ~15 seconds.

Why Go and not Rust?

The TypeScript team evaluated both. Go won for a specific reason: the TS compiler is deeply recursive with a heavily pointer-based data structure. Go's garbage collector and natural support for graph-like data structures made the port more mechanical. Rust would have required fighting the borrow checker on data structures that mutate in place throughout the type-checking pipeline.

This is the same pattern across JS tooling:

• Biome: ESLint + Prettier → Rust, 10-100x faster
• SWC: Babel → Rust, 20x faster
• esbuild: webpack → Go, 10-100x faster
• Rolldown: Vite's bundler → Rust

The lesson: JavaScript tools written in JavaScript hit a ceiling. Native compilers win on large codebases. The TypeScript team is applying this to their own tool.

What does NOT change

This is critical: the TypeScript language is not changing. The Go rewrite is a compiler implementation change, not a language redesign.

• TypeScript syntax: identical
• Type system semantics: identical
• .d.ts output: identical (this was a hard requirement)
• tsconfig.json format: identical
• IDE integration (LSP): same protocol, significantly faster

You will not rewrite a single line of TypeScript. You will just wait less for your build.

What does change

The compiler is no longer written in TypeScript itself. TypeScript was historically bootstrapped — it compiled itself. The Go port breaks that property. For the vast majority of developers, this is irrelevant.

npm package ships native binaries — similar to how esbuild, SWC, and Biome distribute platform-specific executables. Expect a @typescript/native package, similar to @biomejs/biome.

Language server performance — the LSP powering VS Code, Neovim, WebStorm gets faster. Editor startup on large projects, go-to-definition on deep type chains, rename refactors across 500-file repos — all improve.

Where Things Stand in September 2026

The TS 7.0 Go preview is in Visual Studio 2026 but not yet a public npm package. Expect a public beta in 2027.

What This Means for Your Stack

Next.js and Vite: both use SWC/esbuild for transpilation and skip tsc during builds. Where you feel the speed: tsc --noEmit in your pre-push hook or CI. With TS 7.0, that step stops being the bottleneck.

Angular: the Angular compiler uses TypeScript's compiler APIs directly. The Angular team will update to the Go-based APIs — expect a migration period similar to Ivy.

Large monorepos: Turborepo or Nx with 50+ TypeScript packages doing 2-minute type checks get that down to ~15 seconds. That's not marginal — it changes which CI configurations are practical.

Library authors: the .d.ts output from the Go compiler will be byte-for-byte identical. Consumers see no difference.

The Pre-Upgrade Checklist

Before installing TypeScript 6.0 in any project:

# 1. Check for implicit defaults
grep -r '"target"' . --include="tsconfig*.json"
grep -r '"module"' . --include="tsconfig*.json"
 
# 2. Add explicit values for anything missing (see configs above)
 
# 3. If you publish packages, check package type
cat package.json | grep '"type"'
 
# 4. Test with the current stable version before team upgrade
npm install typescript@latest --save-dev
npx tsc --noEmit
 
# 5. Update TypeScript tooling
npm install @typescript-eslint/parser@latest @typescript-eslint/eslint-plugin@latest

After upgrading:

# Verify the target you're actually using
npx tsc --showConfig | grep target
 
# Full type check
npx tsc --noEmit --strict

FAQ

Will TS 7.0 break my TypeScript code? No. The language is identical — same syntax, same type system, same .d.ts output. Breaking changes are in 6.0 (new defaults). 7.0 is a pure performance improvement.

Should I wait for TS 7.0 before addressing the 6.0 changes? No. TS 6.0 is the current release. The new defaults affect you now, not in 2027.

Does the Go rewrite affect Deno or Bun? Both have native TypeScript support via their own transpilers (type-stripped, like Babel). They'll eventually adopt the Go-based LSP for IDE tooling. Their runtime story is largely unaffected.

My team is on TypeScript 4.x. Should we skip to 6.0? Go to 5.x first, then 6.0. Each major has its own strictness improvements and deprecations. Jumping two majors means debugging two sets of breakages simultaneously.

TS 6.0 is the practical problem to address this quarter — audit your tsconfig defaults, add explicit values, test your builds. The full breaking changes migration guide is at TypeScript 6.0 migration guide.

TS 7.0 is the more exciting story, but it's not your problem today. When it lands, large TypeScript projects will feel genuinely different — the edit-save-check loop becomes fast enough to stop working around.

Update your configs. Watch the Go repo. Ship your product.