TypeScript 7.0 Ships a Go Compiler That Cuts Build Times by 90%

Date: 2026-07-09 Topic: TypeScript 7.0 Officially Released Original: TypeScript 7.0 Officially Released Source: Microsoft TypeScript Blog Domain: 💻 Programming Languages

---

Background

On July 8, 2026, the TypeScript team officially released TypeScript 7.0. This is not an ordinary version upgrade—it is the largest infrastructure change since the project's inception: the entire compiler has been ported from TypeScript/JavaScript to Go, achieving 8 to 12 times faster full-build compilation, and the language service protocol server has been completely rewritten with a multi-threaded architecture.

Since the TypeScript 5.x era, the team had been brewing this "native port" plan. The @typescript/native-preview preview package released last year accumulated over 8.5 million weekly downloads. After a year of internal and external testing, it now officially debuts under the 7.0 version number. Daniel Rosenwasser summarized it in the announcement: "Welcome to the era of the TypeScript native toolchain."

Core Content

Why Go for the Native Port?

The TypeScript team's choice of Go for the native port was driven by clear technical considerations. First, Go compiles to machine code with no JIT warm-up overhead; it runs at full speed from startup. Second, Go's goroutines and shared memory model are naturally suited for parallelizing compilation tasks—in compute-intensive scenarios like type checking, multi-core utilization directly impacts final performance. Third, Go compiles to a single binary, making cross-platform distribution extremely simple.

The execution strategy for the port was to "transplant as faithfully as possible"—preserving the structure and logic of the original code to ensure output consistency between the two compilers. The team rewrote the entire codebase in Go while retaining the type-checking algorithms and semantic rules from the original TypeScript compiler. On this foundation, they leveraged Go's native performance and shared-memory multi-threading capabilities to achieve an order-of-magnitude improvement.

Performance Benchmarks: 8–12x Faster with Lower Memory

TypeScript 7 performs astonishingly well on real-world large projects. The team published a set of public benchmark data comparing full-build compilation times of TypeScript 6 and 7 on several well-known open-source projects:

Project	TS 6 Compile Time	TS 7 Compile Time	Speedup
vscode	125.7 s	10.6 s	11.9x
sentry	139.8 s	15.7 s	8.9x
bluesky	24.3 s	2.8 s	8.7x
playwright	12.8 s	1.47 s	8.7x
tldraw	11.2 s	1.46 s	7.7x

Even more impressive is that TypeScript 7 reduces memory consumption while accelerating. The team compared peak memory usage during the same build:

Project	TS 6 Memory	TS 7 Memory	Change
vscode	5.2 GB	4.2 GB	18% reduction
bluesky	1.8 GB	1.3 GB	26% reduction
sentry	4.9 GB	4.6 GB	6% reduction
playwright	1.0 GB	0.9 GB	11% reduction
tldraw	0.6 GB	0.5 GB	15% reduction

Memory usage drops while speed increases, thanks to Go's memory management and more compact data structures. VS Code's compilation peak dropped from 5.2GB to 4.2GB—a tangible benefit for CI environments and memory-constrained development machines.

The improvement in editor experience is immediate. Taking VS Code itself as an example, previously opening a file containing errors took about 17.5 seconds from opening to seeing the first error hint—developers could go grab a glass of water and come back. In TypeScript 7, this time is reduced to under 1.3 seconds, a more than 13x improvement, truly achieving "see it as you open it."

Parallelization Architecture: --checkers and --builders

TypeScript 7's parallelization is multi-layered. Parsing and generation phases are naturally parallelizable because there are few inter-file dependencies. Type checking, however, is much more complex—files share type information, and the order of checking affects result consistency.

To solve this, TypeScript 7 introduces a fixed number of type-checker workers. Each worker has an independent type view; they may duplicate some common computations, but for the same input files, they always partition work in the same way and produce consistent results. The default number of workers is 4, adjustable via the --checkers parameter.

On machines with more cores, increasing to 8 workers can further exploit hardware potential:

Project	TS 7 (4 checkers)	TS 7 (8 checkers)	Speedup vs TS 6
vscode	10.6 s	7.51 s	16.7x
sentry	15.7 s	12.08 s	11.6x
bluesky	2.8 s	2.01 s	12.1x
playwright	1.47 s	1.16 s	11.0x
tldraw	1.46 s	1.06 s	10.6x

vscode achieves a 16.7x speedup with 8 checkers—marginal gains from large-scale parallelization. However, the team also cautions that in resource-constrained scenarios like CI environments, setting --checkers 1 can eliminate duplicate computation and reduce memory overhead. For debugging scenarios, a --singleThreaded flag is provided to completely disable parallelization.

Brand New --watch Mode

TypeScript 7's --watch mode has been completely rewritten, using the Parcel bundler's file watcher underneath—@parcel/watcher developed by Devon Govett. The team faced a dilemma: Parcel's watcher is written in C++; depending on it directly would require introducing a full C++ toolchain for compilation, conflicting with Go's single-binary distribution philosophy.

The solution: port the C++ code to Go, retaining only a small amount of assembly shims. This porting process began with a direct C++-to-Go translation and was progressively optimized into idiomatic Go code, all while passing a complete port test suite. The new watcher is a self-contained package that achieves separation of concerns, significantly reducing resource consumption in --watch mode, especially when monitoring node_modules dependencies of large projects.

Major Changes to Configuration Defaults

TypeScript 7 adopts the new defaults introduced in TypeScript 6 (hence the team strongly recommends users upgrade to TS 6 first, then migrate to 7). Here are the noteworthy changes:

• strict: true enabled by default—meaning noImplicitAny, strictNullChecks, and all other strict checks are on by default
• module: "esnext" outputs ES Module by default, no longer generating CommonJS by default
• target defaults to the latest stable ECMAScript version
• noUncheckedSideEffectImports: true checks whether import statements have actual type exports by default
• libReplacement: false disables automatic replacement of built-in type libraries
• stableTypeOrdering: true and cannot be turned off—guarantees stable type ordering
• rootDir: "./" defaults the root directory to the project root; source directories like src/ must be explicitly specified
• types: [] no longer auto-loads any @types packages by default—previously packages like @types/node were auto-loaded; now they must be declared manually

The last two changes have the broadest impact. Previously, many projects worked fine without setting rootDir; now if tsconfig.json is at the project root and source code is in a src/ directory, rootDir: "./src" must be explicitly specified. The types field change means projects that relied on automatic type loading need to manually add dependencies:

{
  "compilerOptions": {
    "types": ["node", "jest"]
  }
}

Major Deprecations: Farewell to the Old Era

The following features marked as deprecated in TS 6 become hard errors in 7.0:

• target: es5 no longer supported—the ES5 compilation target is officially retired
• module: amd / umd / systemjs / none no longer supported—recommend switching to esnext or preserve
• moduleResolution: node / node10 / classic no longer supported—recommend switching to bundler or nodenext
• baseUrl no longer supported—paths now use project-root-relative notation
• esModuleInterop and allowSyntheticDefaultImports cannot be set to false
• alwaysStrict is always true and cannot be turned off
• The module keyword inside namespaces can no longer be used
• The asserts keyword on imports must be changed to with (aligning with ECMAScript Import Attributes syntax)

The direction of these changes is very clear: TypeScript is fully embracing the modern ECMAScript ecosystem, thoroughly parting ways with old module systems, compilation targets, and resolution strategies. For teams still maintaining legacy projects that depend on AMD modules or ES5 output, this means unavoidable migration work.

Template Literal Types: Finally Unicode Codepoint Support

TypeScript 7 fixes a long-standing Unicode pain point. Previously, template literal types would split Unicode characters by UTF-16 code units when matching, causing non-BMP characters like emoji to be incorrectly split into two surrogate pairs:

type HeadTail<S> = S extends `${infer Head}${infer Tail}` ? [Head, Tail] : never;
type Result = HeadTail<"😀abc">;
// TS 6: ["\ud83d", "\ude00abc"]    split by UTF-16 code units, returns two surrogate pairs
// TS 7: ["😀", "abc"]               split by Unicode codepoints, intuitive

In TypeScript 7, template literal behavior aligns with for...of or [...str]—operating on Unicode codepoints. This is a breaking change that affects code deliberately simulating UTF-16 behavior (such as implementing a string Length utility type), but in practice, the new behavior is more useful and intuitive.

JavaScript Support Refactoring

TypeScript 7 also redesigns the type inference mechanism for JavaScript files, making it more consistent with .ts file analysis. Previously, TypeScript's support for JS files was built on JSDoc comments and various coding pattern heuristics, accumulating numerous special branches and compromises for compatibility with Closure Compiler and the ancient JSDoc ecosystem.

After this refactoring, the main changes include:

• @enum in JSDoc is no longer specially recognized; use @typedef instead
• @class no longer implicitly marks constructors
• The postfix ! no longer supports type assertions—just use T directly
• Closure-style function(string): void syntax is no longer supported—use TypeScript-style (s: string) => void
• Type names must be defined within @typedef tags

These changes most significantly impact projects primarily using JS + JSDoc. Teams heavily relying on JSDoc type annotations will need to check each one during migration.

Compatibility Scheme with TS 6

Since TypeScript 7 does not provide a programmatic API (the new API will be introduced in 7.1), there is a transition period for toolchain adaptation. To address this, the team released the @typescript/typescript6 compatibility package, providing the tsc6 command and full TS 6 API exports. Through npm aliasing, both versions can be installed simultaneously in a single project:

{
  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  }
}

With this configuration, npx tsc uses TypeScript 7 for compilation, while tools like typescript-eslint continue to use the TypeScript 6 API through peer dependencies. Note that projects using embedded languages like Vue, MDX, Astro, or Svelte can only use TS 6 for now—these frameworks depend on API integration with tools like Volar, and TS 7 does not yet expose a stable API. The team is actively following up, expecting resolution in 7.1.

Editor Experience and Production Validation

For VS Code users, the TypeScript team provides a standalone extension that automatically enables the TypeScript 7 language server upon installation. Visual Studio also enables it automatically based on the workspace. The new language server is based on the LSP protocol and supports multi-threaded concurrent request processing. According to the team's telemetry data, compared to the TS 6 language server, the new version reduces language server command failure rates by over 80% and server crash rates by over 60%.

TypeScript 7 has undergone large-scale testing and validation. Internal teams include VS Code, Loop, Office, PowerBI, Teams, and Xbox; external partners include Bloomberg, Canva, Figma, Google, Linear, Notion, Sentry, Slack, Vercel, VoidZero, and others.

Actual user feedback data is impressive:

• Slack: TypeScript 7 eliminated 40% of merge queue wait time; CI type checking dropped from 7.5 minutes to 1.25 minutes; previously the editor was nearly "unusable" on large codebases, with developers relying solely on CI for full type checking—now it loads in seconds, making local type checking practically feasible
• Vanta: Largest project achieved 9x compilation speedup
• Microsoft News Services: Saves 400 hours of CI wait time per month
• Canva: First error hint in the editor dropped from 58 seconds to 4.8 seconds
• Microsoft PowerBI Team: Set TS 7 as the default experience even when it didn't yet support VS Code rename functionality, describing it in the team's own words as a "life-saving improvement"
• Microsoft Loop Team: Previous editor experience was "completely unusable" at monorepo scale; the TS 7 experience was described as "amazing"

Future Roadmap

The release of TypeScript 7.0 marks the conclusion of the major compiler rewrite project. The team's next focus will return to new feature development, usability improvements, further performance optimization, and new API design. TypeScript 7.1 will be released within the next 3–4 months, introducing a stable programmatic API to help embedded language frameworks like Vue, Svelte, and Astro access native acceleration capabilities.

Summary and Outlook

TypeScript 7.0 is one of the most important versions in the project's twelve-year history. The 8–12x speedup from rewriting the compiler in Go is not just a numerical improvement—it fundamentally changes developers' workflows: editor responsiveness shifts from "waiting" to "instantaneous," CI goes from "time for a coffee break" to "done in seconds," and the improvement in inner-loop feedback speed ultimately translates to higher development efficiency and better code quality.

Of course, migration is not without cost. Changes to configuration defaults, removal of numerous deprecated options, and the refactoring of JavaScript JSDoc support—all mean teams need to invest some migration effort during the upgrade. But the direction is clear: TypeScript is fully embracing modern ECMAScript standards, making a clean break from old-era module systems and compilation targets.

Welcome to the era of the TypeScript native toolchain.