Build1 publisher3 min readPublished
TypeScript 7's Go compiler speedup scales with how much of your build is tsc
Microsoft's Go port of the TypeScript 7 compiler cut VS Code's full build from 125.7 to 10.6 seconds in its benchmarks. Tools that import TypeScript as a library may still need the TypeScript 6 API, so the upgrade belongs on a throwaway branch first.
The Engineer · Build desk
What happened
- Microsoft ported both the TypeScript compiler and its language service from the old JavaScript implementation to native Go code.
- Microsoft reports typical full-build gains of 8x to 12x on large codebases, along with lower aggregate memory use in its published benchmarks.
- Microsoft ships an @typescript/typescript6 compatibility package so tools needing programmatic access keep it while TypeScript 7 compiles.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint Projects with transformers, compiler plugins or declaration tools that import TypeScript will run two TypeScript packages side by side until a stable 7.x API exists.
- cost The branch test costs the same effort everywhere, but on a repository the size of tldraw it buys back under 10 seconds per full build.
- decision CI and local machines must resolve the same TypeScript version, or the branch test times a compiler that production builds never use.
The multiplier in Microsoft's table changes with the repository. Worked out from the published times, VS Code built 11.9 times faster [1], Sentry 8.9 times [2], Playwright 8.7 times [3] and tldraw 7.7 times [4]. The tldraw result lands just under the 8x floor of the range Microsoft calls typical for large codebases [3], a shortfall its developers will presumably survive. In absolute terms, VS Code gets back 115.1 seconds per full build [5]. For tldraw it is 9.74 [6].
These are timings of someone else's build. They carry over to yours only if type checking is most of your wall-clock time. If it is half, a checker that runs 10 times faster cuts the whole pipeline by 45% [7]. The dev.to post that collected Microsoft's figures, written by johnnylemonny, says a small application that spends most of its build time bundling assets or running tests may see a less dramatic end-to-end improvement [9]. The author puts the upgrade question this way: "How much of my development time is actually controlled by TypeScript?" [10] The language service moved to Go along with the compiler [1]. The post expects faster editor diagnostics to matter more to many developers than another second off a short production build [11].
The second condition is that your tools run `tsc` as a command. TypeScript 7.0 does not ship a stable programmatic compiler API [6]. Custom transformers, compiler plugins, embedded-language tooling, declaration tools and some framework integrations import TypeScript as a library, and may still depend on the TypeScript 6 API [7]. For those, Microsoft provides the @typescript/typescript6 package. It keeps programmatic access working while TypeScript 7 handles compilation [8]. Shipping the old API next to the new compiler is, in my view, the right call for a port of this size.
The test fits on a short-lived branch. The post lays it out in this order:
1. On a clean tree, record `npx tsc --version`, then time the existing check with `time npx tsc --noEmit`, or `time npx tsc --build --force` for a project with references [12]. 2. Time the rest of the workflow: `npm run lint`, `npm test`, `npm run build` [12]. 3. Run `git switch -c test/typescript-7`, then `npm install --save-dev typescript@latest`, then `npx tsc --version` again to confirm the local executable changed [14]. 4. Repeat every command, plus any declaration generation, API extraction, code generation or framework-specific build [15]. 5. Check what a timing table misses: auto-imports, find-all-references, unexpected changes to declaration files, whether the framework build used the new compiler, peer-dependency complaints from linting, and whether CI ran the same TypeScript version [16].
Each timing needs several runs under similar conditions. The post warns against comparing a cold first run with a warm second one and calling the difference a compiler improvement [13].
Step five is where tools still tied to the TypeScript 6 API show up [7] [16]. On the type check itself, the author wrote: "A successful tsc --noEmit result is necessary, but it is not the whole migration test." [17]
What to watch
- Whether a later TypeScript 7 release ships a stable programmatic compiler API that transformers and plugins can move to.
- Framework build tools and linters confirming they run on the native compiler instead of the TypeScript 6 package.
- Independent full-build timings from repositories smaller than tldraw, where Microsoft's published multiplier was lowest.