TypeScript 7 RC introduces Go-rewritten compiler with claimed tenfold speedup

Microsoft ports its flagship compiler to Go, promising massive build-time improvements while introducing strict breaking changes that require a staged migration path from version 6.

The Answer Up Front\n\nIf you run a large TypeScript codebase where slow builds stall your CI/CD pipelines, you should prepare to migrate to TypeScript 7 immediately. For teams with complex build pipelines dependent on programmatic APIs like typescript-eslint, a direct upgrade is not yet viable. The bottom line is that while the Go-powered compiler engine delivers massive speedups, the breaking changes and delayed programmatic API mean most teams must adopt a staged migration using TypeScript 6 as a bridge.\n\n## Methodology\n\nThis v0 review draws on the published claims from the Microsoft Release Candidate announcement and early reports from enterprise testers at Figma, Bloomberg, Vercel, Notion, and Slack. Independent benchmarks are pending. Update cadence: we will re-test when the stable version launches and when claims diverge from observed behavior. This review covers the architectural shift from a self-hosted TypeScript compiler to a native Go implementation, the deprecation of legacy configuration flags, and the side-by-side installation strategy. It does not cover independent performance benchmarks, long-term workflow stability, or edge cases in complex type-checking scenarios.\n\n## What It Does\n\n### A native Go compiler engine\nThe core change in TypeScript 7 is the rewrite of the compiler (tsc) from TypeScript to Go. The repository is open source under the Apache 2.0 license, with over 25,000 stars on GitHub, and is composed of roughly 85% Go. By compiling to native code and using shared-memory parallelism, the new engine aims to eliminate the performance bottlenecks of running on Node.js. Microsoft reports that builds are often around 10 times faster than TypeScript 6.\n\n### Faster editor feedback loops\nThe architectural rewrite extends to the Language Server Protocol (LSP), which powers autocompletion, type hovers, and real-time error reporting in IDEs. Because the LSP runs on the same Go-based foundation, editor responsiveness is expected to improve noticeably, particularly on large codebases where type-checking latency previously degraded the developer experience.\n\n### Strict configuration defaults\nTypeScript 7 enforces strict defaults and turns several options deprecated in version 6 into hard errors. Legacy options like target: es5, moduleResolution: node, baseUrl, and module: amd/umd/systemjs are no longer supported. Instead, strict now defaults to true, and module defaults to esnext. Additionally, rootDir now defaults to ./ and types defaults to [], requiring developers to explicitly list their @types packages.\n\n### Side-by-side execution compatibility\nBecause tools like typescript-eslint import the typescript package directly and require the stable programmatic API (which is delayed until TypeScript 7.1), Microsoft provides a compatibility package called @typescript/typescript6. This package ships a tsc6 binary and re-exports the version 6 API. Developers can run both versions side-by-side using npm aliases in their package.json.\n\n## What's Interesting / What's Not\n\nThe decision to rewrite the compiler in Go rather than Rust is the most interesting architectural choice. While Rust has become the default language for modern web tooling, Microsoft chose Go. This choice likely prioritized Go's rapid compilation times, simpler concurrency model, and easier path for porting the existing garbage-collected TypeScript codebase. The team claims that they ported the existing codebase methodically rather than rewriting it from scratch, ensuring that the type-checking logic remains structurally identical to TypeScript 6.\n\nWhat is less impressive is the fragmentation of the ecosystem at launch. The stable programmatic API will not land until TypeScript 7.1, which is expected several months after the initial release. This means that critical developer tools, particularly typescript-eslint, cannot fully support the native Go compiler on day one. The recommended workaround of using npm aliases to run version 6 and version 7 side-by-side is a pragmatic but messy stopgap. It forces developers to maintain two compiler versions in their dependency trees, adding complexity to configuration and CI pipelines.\n\n## Pricing\n\nTypeScript is free and open-source software licensed under the Apache 2.0 license. There are no paid tiers or usage limits. Pricing snapshot date: June 21, 2026.\n\n## Verdict\n\nTypeScript 7 RC represents a major architectural shift that addresses the language's biggest historical weakness: compiler performance. If you have a large codebase, the promise of a tenfold speedup is too significant to ignore, but you should not jump directly from version 5 to 7. We recommend upgrading to TypeScript 6 first to resolve all deprecation warnings before attempting the transition to the Go-powered compiler. For teams heavily reliant on programmatic APIs and linting tools, wait for the TypeScript 7.1 release to avoid complex npm aliasing workarounds.\n\n## What We'd Test Next\n\nWe want to run independent benchmarks comparing TypeScript 6 and 7 on medium and large codebases to verify the claimed tenfold speedup. We will also test the memory footprint of the Go-based compiler against the Node.js implementation under heavy load. Finally, we need to evaluate the stability of the side-by-side npm aliasing workaround in monorepo setups using pnpm and Yarn.

The investor read

The TypeScript 7 release is a major event for the developer tooling ecosystem, signaling a broader shift away from JavaScript-based compilers toward native languages. While Rust has captured venture attention through projects like Turbopack and Rolldown, Microsoft's choice of Go for its flagship compiler demonstrates that Go remains a highly competitive runtime for enterprise-scale tooling. For investors, this move highlights that developer productivity is increasingly gated by build performance, driving capital and engineering talent toward native rewrites of the web stack. It also suggests that the developer tooling market is consolidating around native-performance runtimes, making pure-JS tooling startups less competitive unless they plan native rewrites from day one.

Pull quote: “The decision to rewrite the compiler in Go rather than Rust is the most interesting architectural choice.”