Independent benchmark: TypeScript 7.1 beta checks 353k-line NestJS project in 2.8s, down from 12.4s

A real project instead of a release benchmark

An independent benchmark published on dev.to set out to test the native TypeScript compiler on a codebase nobody picked for a marketing slide: a fresh clone of the NestJS framework with its actual dependencies installed. Spanning 2,934 files and about 353,000 lines, the project was type-checked with tsc --noEmit — the work a CI pipeline or pre-commit hook does daily — under three compiler versions: 6.0.3, the last JavaScript-based release; 7.0.2, the first stable native release; and 7.1.0-beta. Each version ran three times on the same machine and checkout, with the fastest time reported.

Compiler	Fastest run	Peak memory
TypeScript 6.0.3	12.42s	1.13 GB
TypeScript 7.0.2	4.95s	1.86 GB
TypeScript 7.1.0-beta	2.76s	1.06 GB

Big gains, smaller than the headline

Microsoft's release materials, as cited in the post, describe the Go-based rewrite cutting one compile from 125.7 seconds to 10.6 seconds, roughly a 12x improvement. On NestJS the picture is more modest: according to the dev.to benchmark, 7.0.2 is 2.5x faster than 6.0.3 and the 7.1 beta is 4.5x faster. The author's practical guidance is that projects resembling a mid-sized Node framework rather than the TypeScript compiler's own type-heavy source should plan for a 2.5x to 4.5x speedup, not 12x.

The memory detour in 7.0.2

One result runs counter to what a native rewrite is supposed to deliver. Across all three runs, 7.0.2 peaked at about 65% more memory than the JavaScript compiler it replaced — roughly 1.8 GB versus 1.13 GB. The author warns that a CI runner sized for TypeScript 6's footprint could hit out-of-memory failures on 7.0.2. The 7.1 beta reverses the regression, landing slightly below 6.0.3 at around 1.06 GB. No root cause is offered beyond the consistent observations.

The old JavaScript API stays broken

The rewrite removed the programmatic interface that tooling has depended on for years. In 7.0.2, requiring the typescript package yields only version strings — no createProgram, no ts.sys. The author confirmed this by pointing ts-node 10.9.2 at the new compiler, which crashed immediately. Because the beta's headline feature is a stabilized API, the author expected restoration; instead, 7.1 ships a new interface at typescript/sync and typescript/async, moved from 7.0's typescript/unstable/sync path, while the default export remains version-only. The same ts-node test produced the identical crash on the beta. Tools that call the compiler programmatically rather than shelling out — ts-node, ts-jest, and the type-aware rules in typescript-eslint — need to be rewritten against the new entry points; a version bump alone fixes nothing.

Stricter configs and parallel builds by default

Configuration files can also block upgrades. The deprecated option importsNotUsedAsValues was accepted without complaint by 6.0.3 but produces a hard error under 7.0. The author recommends grepping older tsconfig files for previously ignorable options before upgrading.

On the performance side, parallel project-reference builds are now the default, with a --singleThreaded flag as the escape hatch. On a synthetic four-package composite project, 7.0.2's default mode finished in under a second, versus about 1.4 seconds single-threaded and 4.26 seconds on 6.0.3 — roughly 1.8x from parallelism alone on a four-core machine, stacked on top of the native checker's raw speed. The author expects the gap to widen on larger monorepos with more independent projects and more cores.

Diagnostics show where the win comes from

According to --extendedDiagnostics output in the post, type checking dominates wall-clock time in every version and is where the native compiler gains most proportionally: parse time fell from 1.16s to 0.291s, bind time from 0.61s to 0.093s, and check time from 9.91s to 2.502s. Codebases that spend most of their effort parsing rather than checking will see smaller wins. The author also cautions that the Symbols and Types counters roughly doubled between versions on identical code, most likely reflecting a change in internal accounting rather than real work.

Why it matters

The benchmark independently verifies that the native rewrite delivers a major, everyday speedup — turning a 12-second check into under 3 seconds on a representative project — while calibrating expectations well below Microsoft's advertised multiples. It also maps the real upgrade cost: higher memory on the current stable release, a still-broken classic API that the wider tooling ecosystem must migrate off, and stricter config validation. Teams planning the jump should measure their own diagnostics output before and after, and size CI runners with 7.0.2's memory footprint in mind.