TypeScript 7 tested on M4 Mac mini: 3.9x-7.3x, not 10x, on type-heavy code
Contents
TypeScript 7 is officially out — the compiler and language server ported wholesale to Go, with an official claim of “8-12x faster full builds.”
I installed it on release day on an M4 Mac mini (10 cores / 16GB) and ran it against the kind of codebases the official benchmarks don’t cover.
Where files are many and types are simple, the claim mostly holds: lobe-chat came in at 7.3x. Type-heavy code fared worse — Effect got 5.3x and drizzle-orm 3.9x, below the low end of the official range.
On a 16GB machine, --checkers 8 — which the official post presents as a way to go even faster — made things slower by crowding out memory.
And ComfyUI_frontend, being a Vue app, couldn’t run it at all.
What changed in TypeScript 7
The Go port announced in March 2025 is now the stable release.
| Item | Details |
|---|---|
| Native port | Go implementation with shared-memory multithreading. Official figure: 8-12x on full builds |
| Editor support | Official Language Server Protocol (LSP) support. VS Code has a dedicated extension, shipping in VS Code itself in the coming weeks |
| Parallelism controls | --checkers (type-check workers, default 4), --builders (parallel project-reference builds), --singleThreaded |
| Watch mode | New implementation based on a Go port of Parcel’s file watcher (originally C++) |
| API | None. A newly designed API is planned for 7.1. Until then there is @typescript/typescript6 (a tsc6 binary plus the 6.0 API) |
| Compatibility | Type-checking results match 6.0. Flags deprecated in 6.0 are now hard errors |
The npm package name stays typescript even for the native version; npm install -D typescript@7 is all it takes.
The packaging follows the esbuild approach: platform-specific packages like @typescript/typescript-darwin-arm64 carry the native binary, and bin/tsc is a thin Node wrapper.
I covered 6.0’s breaking changes (strict on by default, baseUrl removal, and so on) in the TypeScript 6.0 RC article. In 7.0 those become hard errors.
For tools that consume the API, like typescript-eslint, the official recommendation is an npm alias setup that keeps the 6.0 line under the typescript name:
{
"devDependencies": {
"typescript": "npm:@typescript/typescript6@^6.0.2",
"typescript-7": "npm:typescript@^7.0.2"
}
}Picking the benchmark targets
The official blog benchmarks five codebases — vscode (125.7s to 10.6s, 11.9x), sentry, bluesky, playwright, tldraw. All of them are application code with lots of files, and the speedups run 7.7x-11.9x.
Parsing and emit can proceed almost independently per file, and type checking splits across 4 workers by default.
Code where type instantiation chains deeply inside a single file, on the other hand, cannot be split up. ORMs that derive types from schema definitions and heavily type-level libraries are absent from the official table.
So I picked these four:
| Repository | Size | Pinned TS | Type-checking profile |
|---|---|---|---|
| drizzle-orm (main package) | 448 files / 62k lines | 5.6.3 | Dominated by type derivation from schemas |
| Effect (whole monorepo) | 1,803 files / 588k lines | 5.8.3 | Type-level programming throughout; tsc -b across 35 packages |
| lobe-chat | 8,451 files / 1.18M lines | 6.0.3 | Large app with straightforward types; the reference point |
| ComfyUI_frontend | 2,694 files / 523k lines | 5.9.3 (vue-tsc) | Vue SFCs included |
lobe-chat and ComfyUI_frontend are the two familiar names from the generative-AI ecosystem.
lobe-chat’s type-check script already runs tsgo --noEmit, so the native preview was already in production use there. This release is the stable version of exactly that.
Test setup
| Item | Details |
|---|---|
| Machine | M4 Mac mini (10 cores / 16GB) |
| Node | 25.3 |
| TypeScript 7 | 7.0.2 (running the @typescript/typescript-darwin-arm64 native binary directly) |
| Baseline | Each repository’s pinned TypeScript version (tsc.js on Node) |
| Measurement | /usr/bin/time -l for wall time and peak memory (max RSS); median of 3 runs |
The baseline is the pinned version on purpose — that is the speed each project’s developers actually see day to day.
Effect was reset to a full build with tsc -b --clean before every run, and TypeScript 7 ran with the default --checkers 4 unless noted.
It won’t run on the existing tsconfig
All three stopped with configuration errors when pointed at their existing tsconfig.
On drizzle-orm, baseUrl is the blocker:
tsconfig.json(4,3): error TS5102: Option 'baseUrl' has been removed. Please remove it from your configuration.
Use '"paths": {"*": ["./*"]}' instead.
tsconfig.json(6,12): error TS5090: Non-relative paths are not allowed. Did you forget a leading './'?Two changes are needed: delete the baseUrl line and rewrite paths to start with ./, as "~/*": ["./src/*"] (TS5090 requires the ./). After that it ran.
Effect got rejected over downlevelIteration and esModuleInterop: false. Both live in tsconfig.base.json, so deleting them takes seconds.
Separate from the flags, jumping from 5.8.3 to 7.0 also moves the bundled lib.d.ts forward several generations. Effect hit the Uint8Array/ArrayBuffer typing changes and produced 34 type errors across 9 files:
packages/platform-node/src/internal/httpIncomingMessage.ts(83,5): error TS2375:
Type 'Effect<Uint8Array<ArrayBufferLike>, E, never>' is not assignable to
type 'Effect<ArrayBuffer, E, never>' with 'exactOptionalPropertyTypes: true'.The compiler itself is carefully compatible — with 6.0. For projects still pinned to 5.x, like drizzle-orm and Effect here, fixing these config and type errors comes before any speed measurement.
Results
Full check wall time (median of 3 runs):
| Repository | Pinned TS | TypeScript 7 | Speedup |
|---|---|---|---|
| drizzle-orm | 3.70s (5.6.3) | 0.94s | 3.9x |
| Effect (tsc -b) | 42.5s (5.8.3) | 8.1s | 5.3x |
| lobe-chat | 112.7s (6.0.3) | 15.4s | 7.3x |
Peak memory (max RSS):
| Repository | Pinned TS | TypeScript 7 |
|---|---|---|
| drizzle-orm | 1.1GB | 1.5GB |
| Effect | 3.1GB | 1.9GB |
| lobe-chat | 7.9GB | 9.5GB |
On lobe-chat, TypeScript 6 crashed Node out of the box and only finished with NODE_OPTIONS=--max-old-space-size=12288. TypeScript 7 is a native process, so that whole class of heap tuning becomes unnecessary.
Peak memory, though, reached 9.5GB on lobe-chat. The official “less memory” claim is about aggregate memory over the span of a build; the peak that parallel workers hold at the same time actually went up.
Adding --builders 8 took Effect from 8.1s to 7.1s (6.0x). The difference comes from packages in the dependency graph that could still build in parallel.
Sweeping —checkers
I swept --checkers across 1, 4 (the default), and 8:
| checkers 1 | checkers 4 | checkers 8 | |
|---|---|---|---|
| drizzle-orm | 1.24s / 0.8GB | 0.94s / 1.5GB | 1.10s / 1.9GB |
| lobe-chat | 22.1s / 7.1GB | 15.4s / 9.5GB | 34.6s / 9.1GB |
First: even single-threaded --checkers 1 gives drizzle-orm 3.0x and lobe-chat 5.1x. Most of the speedup comes from the native code itself, not the parallelism — parallelism contributes another 1.3-1.4x at most.
The official blog notes that each worker keeps its own duplicate view of shared type information. More workers means paying that duplication in memory and startup cost, and on a project as small as drizzle-orm, 8 workers cost more than they return: slower than the default 4.
Second: on lobe-chat, --checkers 8 more than doubled the time, from 15.4s to 34.6s. With peak RSS above 9GB it was competing with everything else for 16GB of physical memory, and the behavior points to swapping.
The official “16.7x on vscode with --checkers 8” number did not reproduce on this 16GB machine. The default of 4 was fastest on both repositories.
It doesn’t run on ComfyUI_frontend
Pointing plain tsc at ComfyUI_frontend, a Vue app, produces 646 errors, all of the same kind:
src/components/actionbar/ComfyActionbar.test.ts(6,28): error TS2307:
Cannot find module '@/components/actionbar/ComfyActionbar.vue' or its corresponding type declarations.Types for .vue files are resolved by vue-tsc (Volar) plugging into TypeScript’s API. TypeScript 7 does not have that API yet.
graph LR
A[.vue SFC] --> B[vue-tsc / Volar]
B --> C[Embeds TypeScript<br/>via its API]
C --> D[Up to TS 6: JS build<br/>has the API]
C --> E[TS 7: native<br/>no API, new one planned for 7.1]The official post is explicit about this: Vue, MDX, Astro, and Svelte workflows (this blog’s Astro included) stay on TypeScript 6.0 for now. Angular gets a suggested split — TypeScript 7 for CLI type checking, TypeScript 6 in the editor — but Vue-style toolchains can’t even do that.
ComfyUI_frontend’s vue-tsc full check runs 20.4s cold (4.7s with a warm tsbuildinfo), and that number stays where it is until the 7.1 API and Volar support land.
Of the four codebases here, the three that are plain TypeScript end to end got faster with TypeScript 7; ComfyUI_frontend is left waiting on the new API and Volar.
The team says feature releases now return to the usual 3-4 month cadence, with 7.1 next.