Microsoft's TypeScript team has released TypeScript 7.0, a native version rewritten in Go. As of the July 8, 2026 announcement, npm install -D typescript now becomes the standard route to installing the new tsc, and on the npm registry, latest for typescript now points to 7.0.2. This marks a shift from the trial phase of @typescript/native-preview to a stage where adoption via the standard package can be seriously considered.
The core of this change isn't new features—it's the implementation foundation of TypeScript itself. Microsoft revealed its plan to port the existing JavaScript implementation to Go back in March 2025. TypeScript 7.0 is the result of that effort: while preserving as much of the original codebase's structure and logic as possible, it incorporates native code speed, multithreading with shared memory, and multiple optimizations. For large-scale frontends and monorepos, type-checking latency directly shapes the development experience itself. 7.0 is a release that tackles this head-on.
An 8x to 12x Reduction Changes the Nature of Waiting
According to Microsoft's measurements, TypeScript 7.0 achieves roughly 8x to 12x faster full builds on large open-source projects. For the VS Code codebase, build time dropped from 125.7 seconds to 10.6 seconds—an 11.9x reduction. Sentry went from 139.8 seconds to 15.7 seconds, Bluesky from 24.3 seconds to 2.8 seconds, Playwright from 12.8 seconds to 1.47 seconds, and tldraw from 11.2 seconds to 1.46 seconds.
Memory usage moves in the same direction. For VS Code, it dropped 18% from 5.2GB to 4.2GB, and for Bluesky, 26% from 1.8GB to 1.3GB. Playwright and tldraw also saw reductions of roughly 10-15%. While results vary across environments, this isn't a port that trades memory for speed.
The difference in editor experience is also substantial. According to the TypeScript team, the time from opening a file containing an error in the VS Code codebase to seeing the first error appear dropped from approximately 17.5 seconds to under 1.3 seconds—a reduction of over 13x. A separate post from the VS Code team notes that type-checking the main source went from 36 seconds in TypeScript 6.0 to 5 seconds in TypeScript 7, while a standard npm run watch shortened from about 80 seconds to just over 20 seconds. The time for the editor to load a project and enable advanced TypeScript features also shrank from nearly a minute to about 10 seconds.
This change isn't aimed solely at human developers. TypeScript's announcement also touches on scenarios where AI agents repeatedly run builds and type checks. In iterative loops of fixing type errors, rechecking, and fixing again, the wait time per cycle directly determines the granularity of work. Rather than weakening the type system, TypeScript 7.0 makes it possible to run the same checks at much shorter intervals.
The Bridge to TypeScript 6.0 Remains for the Transition to 7.0
However, TypeScript 7.0 isn't the final form that completely replaces the traditional TypeScript. The biggest constraint is that 7.0 hasn't yet shipped a programmatic API. The TypeScript team has indicated that a new, different API is planned for release in 7.1. Until then, tools that depend on the compiler API—like typescript-eslint—will still need to rely on TypeScript 6.0 in certain scenarios.
To address this, Microsoft has prepared a compatibility package called @typescript/typescript6. This package includes an executable called tsc6 and also re-exports the TypeScript 6.0 API. According to current npm listings, @typescript/typescript6 is published as version 6.0.2 and provides tsc6. This means developers can run TypeScript 7.0 via tsc while still directing API-dependent tools to use 6.0.
This parallel setup is a more practical approach than rushing ahead based solely on the version number 7.0. As of March 2026, TypeScript 6.0 was already positioned as a bridge for transitioning from 5.9 to 7.0. In 6.0, strict defaults to true, module defaults to esnext, and noUncheckedSideEffectImports is also enabled by default. rootDir now defaults to ./, and types defaults to an empty array—changes that help surface outdated configurations. Since 7.0 assumes this 6.0 behavior as its baseline, clearing out warnings and configuration discrepancies in 6.0 first serves as essential preparation for migrating to 7.0.
Parallelization Is Fast, But CI Requires Watching the Configuration Multiplier
TypeScript 7.0's speed comes not just from native code compilation but also from parallelization. 7.0 runs much of parsing, type checking, and emit in parallel. Type checking uses 4 workers by default, adjustable via --checkers. According to Microsoft's table, using --checkers 8 reduced the VS Code measurement to 7.51 seconds—a 16.7x improvement over TypeScript 6.
However, adding more workers doesn't always yield benefits. Since type checking shares many dependencies, increasing workers can create duplicate work across them. Microsoft itself suggests lowering --checkers in environments with fewer CPU cores, such as CI runners, or with limited memory. For project reference builds, a new --builders option has also been added; specifications like --checkers 4 --builders 4 can result in up to 16 type checkers running simultaneously. In monorepos, increasing these values without considering this multiplier effect can create a different kind of bottleneck.
--watch mode has also been rebuilt. TypeScript 7.0 uses a foundation based on a Go port of Parcel's file watcher. Pure polling places heavy load on large projects or environments with extensive node_modules directories. On the other hand, the original Parcel watcher was written in C++, requiring a C++ toolchain for builds. The TypeScript team chose to move this component to Go, reducing resource consumption during watch mode.
On the configuration front, choices premised on older JavaScript environments are being pushed further into deprecation. In TypeScript 7.0, options deprecated in 6.0—such as target: es5, downlevelIteration, moduleResolution: node or node10, moduleResolution: classic, amd, umd, systemjs, and none—now trigger hard errors. Settings like baseUrl, and setting esModuleInterop and allowSyntheticDefaultImports to false, fall into the same category. TypeScript 7.0 is both a fast port and a milestone for cleaning up legacy defaults.
Boundaries Remain for Embedded Languages and JavaScript Analysis
On the editor side, TypeScript 7.0's language service uses LSP. VS Code has a dedicated TypeScript 7 extension, and Visual Studio automatically enables TypeScript 7 depending on the workspace. According to the announcement, TypeScript 7.0's new language server reduces failing language server commands by over 80% compared to TypeScript 6.0, and cuts server crashes by over 60%.
That said, not every editing experience gets replaced on the same day. Workflows for Vue, MDX, Astro, Svelte, and specialized embedded processing like Angular's in-template type checking all require a stable programmatic API. Since TypeScript 7.0 doesn't yet have that API, these areas will still need to fall back to TypeScript 6.0, or use 7.0 only for broad CLI-based error detection, as an operational workaround.
Handling of JavaScript files has also changed. TypeScript 7.0 revisits the special treatment previously given to JSDoc and older Closure-style notation, bringing it closer to how TypeScript files are parsed. When using a value in a type position, typeof is now required, and certain notations that were previously recognized in some contexts—like @enum or Closure-style function type syntax—will no longer work. This is something projects that rely on JavaScript files for TypeScript's type checking should verify before worrying about build times.
As of the announcement, the preview package @typescript/native-preview had reportedly been downloaded over 8.5 million times per week. Going forward, nightly builds will move back to the next tag on the standard typescript package. On npm, next currently points to a 7.1.0 development version. While the native era begins with 7.0, the broader ecosystem migration will proceed alongside the 7.1 API, framework support updates, and real-world CI configuration testing.