The compiler and language service have been ported to Go. Microsoft reports typical full-build improvements between 8x and 12x in large codebases, along with lower aggregate memory use in its published benchmarks.
A faster compiler is useful only if your framework build, declaration output, editor, project references, linting, and surrounding tools still behave correctly.
You need a temporary branch, your existing verification commands, and two comparable timings.
The goal is to learn whether TypeScript 7 improves your project without breaking the workflow around it.
TypeScript 7 replaces the previous JavaScript-based compiler and language service with a native implementation written in Go. The new implementation uses native code, shared-memory multithreading, and other optimizations intended to preserve familiar TypeScript behavior while substantially reducing wait times.
Microsoft's published full-build results include: VS Code: 125.7 seconds to 10.6 seconds Sentry: 139.8 seconds to 15.7 seconds Playwright: 12.8 seconds to 1.47 seconds tldraw: 11.2 seconds to 1.46 seconds
Those are impressive results, but they are not a promise about every repository. A small application that spends most of its build time bundling assets or running tests may see a less dramatic end-to-end improvement.
Do not compare a cold first run with a warm second run and call the difference a compiler improvement. Run each measurement several times under similar conditions.
The editor measurement can be approximate. Open the same workspace and observe how long it takes before diagnostics, references, and completions become useful.
If the repository uses project references, declaration generation, API extraction, code generation, or framework-specific builds, run those too.
A successful tsc --noEmit result is necessary, but it is not the whole migration test.
The most useful observations may not fit in a timing table: Did the editor load the project faster? Did auto-imports behave normally? Did find-all-references return complete results? Did declaration files change unexpectedly? Did the framework build use the new compiler? Did linting or another tool report an incompatible peer dependency? Did CI use the same TypeScript version as the local test?
For many developers, faster diagnostics in the editor will matter more than shaving another second from an already short production build.
That matters when a tool imports TypeScript as a library instead of simply invoking tsc. Custom transformers, compiler plugins, embedded-language tooling, declaration tools, and some framework integrations may still depend on the TypeScript 6 API.
Microsoft provides the @typescript/typescript6 compatibility package for tools that still need programmatic access while TypeScript 7 handles compilation.
In this arrangement, the TypeScript 6 compatibility package remains available to tools expecting the established API, while the aliased native package supplies the TypeScript 7 compiler.
Do not add this workaround automatically. First identify whether any tool in your project actually needs it, then follow that tool's current migration guidance.
Take extra care if your project uses: custom TypeScript transformers, tools that import the compiler API, framework-specific template type checking, MDX or embedded languages, declaration bundlers, compiler-based code generation, complex project references, editor plugins tied to the older language service, build systems that pin a particular TypeScript range.