TypeScript 7: Is tsc Really 7x Faster?

TypeScript 7 upgrade decision with ShopperCove timing on Hono (906 files): median 10.23 s on 6.0.3 vs 1.41 s on 7.0.2 (7.3x), peak RSS 1,032 MB vs 718 MB, plus 2 moved @ts-expect-error targets and the typescript-eslint <6.1 peer limit.

5 October 20267 min read

Summary

Yes, move your command-line type-check to TypeScript 7 if your project already passes TypeScript 6.0 with no deprecation errors: on Hono's 906-file test project, 7.0.2 cut the median check from 10.23 s to 1.41 s (7.3x) and peak memory from 1,032 MB to 718 MB. Wait on the editor side if you use Vue, Svelte, Astro, MDX or type-aware typescript-eslint, because 7.0 ships without a programmatic API and typescript-eslint 8.71.0 still caps its peer range below 6.1.

What I tested

Machine: 8 vCPU / 15 GB RAM Linux cloud box (kernel 6.12). Node 24.21.0 runs TypeScript 6; TypeScript 7 is a native Go binary.
Compilers: typescript@6.0.3 and typescript@7.0.2, installed side by side with npm aliases.
Codebase: Hono main at commit 5f36607 (5 Oct 2026, 14:59 IST), package version 4.13.13, dependencies from its lockfile via pnpm 12.6.0.
Command: tsc -p <config> --noEmit, three runs per cell, median reported. Peak memory is max RSS from getrusage.
One surprise: Hono's base config sets composite: true, so a leftover .tsbuildinfo turns the next run into an incremental check. My first pass showed TypeScript 7 at 0.23 s for that reason. I deleted the build info before every timed run below.
Not tested: editor and LSP latency, --build with project references, emit, watch mode, Windows or macOS.

How much faster is TypeScript 7 on a real project?

Hono config	Files	TS 6.0.3 median	TS 7.0.2 median	Speedup	Peak RSS (6 → 7)
`tsconfig.build.json` (src only)	363	3.02 s (3.02 / 2.95 / 3.09)	0.65 s (0.70 / 0.65 / 0.63)	4.6x	524 MB → 337 MB
`tsconfig.spec.json` (src + tests)	906	10.23 s (9.59 / 10.37 / 10.23)	1.41 s (1.41 / 1.45 / 1.41)	7.3x	1,032 MB → 718 MB

Microsoft's TypeScript 7.0 announcement reports 8x to 12x on much bigger codebases such as VS Code (125.7 s → 10.6 s). My numbers sit below that range, which is what I expected: on a 363-file project, process start and setup are a bigger share of the total. The larger Hono config got closer to the official range.

With the build info left in place, a no-change second run took 0.23 s on 7.0.2 and 1.50 s on 6.0.3 (one run each).

Does --checkers help on an 8-core machine?

TypeScript 7 runs 4 type-checker workers by default. I timed the 906-file config with the new flags:

TS 7.0.2 flag	Median	Peak RSS
default (4 checkers)	1.41 s	718 MB
`--checkers 8`	1.46 s (1.41 / 1.53 / 1.46)	872 MB
`--checkers 1`	2.74 s (2.74 / 2.86 / 2.52)	552 MB
`--singleThreaded`	2.94 s (2.94 / 3.00 / 2.83)	552 MB

Doubling checkers bought nothing at this size and cost about 150 MB more. Even fully single-threaded, 7.0.2 beat 6.0.3 by about 3.5x. On small CI runners I would pin --checkers 2 or --checkers 1. Pinning a fixed number also keeps results identical across machines, which the TypeScript team recommends because checker count can surface order-dependent results in rare cases.

Will TypeScript 7 break my build?

I hit two kinds of breakage.

Config errors. I wrote a small legacy tsconfig.json with target: es5, moduleResolution: node, baseUrl plus a non-relative paths entry, and downlevelIteration. TypeScript 6.0.3 already flags these as deprecated (TS5107 / TS5101) unless you set ignoreDeprecations: "6.0". TypeScript 7.0.2 removes the escape hatch: it prints TS5108 / TS5102 "has been removed" for each option, plus TS5090 "Non-relative paths are not allowed" for the paths entry that leaned on baseUrl. Fix these on 6.0 first.

Diagnostic placement. Hono's test suite has two // @ts-expect-error comments above app.on( calls with ten middleware arguments. With the directives removed, 6.0.3 reports TS2769 "No overload matches this call" at line 3417 (the app.on( line). 7.0.2 reports the same error two lines lower, on the '/on/10' argument. Because a directive only covers the next line, 7.0.2 shows TS2578 "Unused '@ts-expect-error' directive" plus the uncovered TS2769, which makes 4 diagnostics for 2 real differences. If you use @ts-expect-error on multi-line calls, expect a few of these.

Tooling. typescript-eslint 8.71.0 declares typescript: ">=4.8.4 <6.1.0" as its peer range, so type-aware lint stays on 6.0 for now. I covered its newest rule in the typescript-eslint 8.71 post. Vue projects should keep 6.0 for vue-tsc too; see the vue-tsc 3.3.12 notes.

How do I upgrade without breaking lint?

Get clean on TypeScript 6.0 with no ignoreDeprecations setting. Add rootDir and an explicit types list if you relied on the old defaults (7.0 defaults types to []).
Use the alias setup from the announcement so tsc is 7.0 and every tool importing typescript still gets 6.0:

{
  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  }
}

Run tsc --noEmit (7.0) and tsc6 --noEmit (6.0) in CI for a week and diff the output. Look for moved @ts-expect-error targets first.
Pin --checkers in CI.
In VS Code, install the TypeScript 7 extension. For Vue, Svelte, Astro or MDX workspaces, run "Disable TypeScript 7 Language Server" until 7.1 ships its API. The same holds if you are on the Astro 7.3 preview or a SvelteKit 3 migration.

Should you upgrade to TypeScript 7?

Your setup	My call
Plain TS or React app, `bundler` or `nodenext` resolution, clean on 6.0	Upgrade CLI and editor now
Type-aware typescript-eslint	Upgrade `tsc` through the alias; keep 6.0 for lint
Angular	TS 7 for CLI checks, 6.0 for template type-checking in the editor
Vue, Svelte, Astro, MDX	CLI checks only where possible; editor stays on 6.0 until 7.1
`target: es5`, `baseUrl`, `node10` resolution	Fix the config on 6.0 first
Custom transformers or loaders that import the `typescript` API	Wait for 7.1

Bottom line: on Hono the type-check went from about 10 seconds to about 1.4 seconds with 30% less memory, and the only code changes needed were two moved @ts-expect-error comments. Who should not bother yet: teams whose day-to-day pain is in Vue or Svelte editor tooling, because 7.0 does not reach there.

How this was made: I ran every command above on the ShopperCove test box and kept the raw output; the write-up was drafted with AI help and checked="true" against that output.

FAQ

How much faster is TypeScript 7?

On Hono, 4.6x on the 363-file src config (3.02 s to 0.65 s) and 7.3x on the 906-file spec config (10.23 s to 1.41 s). Microsoft reports 8x to 12x on much larger codebases.

Will TypeScript 7 break my build?

Possibly. Options deprecated in 6.0 (target es5, baseUrl, node10 resolution) are removed, and ts-expect-error on multi-line calls can land on the wrong line. Hono needed two moved directives.

Does typescript-eslint work with TypeScript 7?

Not yet. typescript-eslint 8.71.0 declares typescript>=4.8.4 <6.1.0, so use the npm alias setup to keep 6.0 for lint while tsc runs 7.0.

Sources

typescript 7 should you upgrade typescript 7 vs 6 benchmark typescript 7.0.2 tsc speed typescript 7 typescript-eslint typescript 7 checkers flag @typescript/typescript6 alias

Lab evidence

What I found running this

Sources read 5 Oct 2026 evening (Asia/Calcutta): devblogs.microsoft.com/typescript/announcing-typescript-7-0/ (8 Jul 2026; 8-12x claim; no API until 7.1; @typescript/typescript6 alias; defaults strict/esnext/types=[]; removed es5/baseUrl/node10). npm typescript latest=7.0.2 (published 2026-07-08T15:55Z, ~21:25 IST); typescript-eslint 8.71.0 peer typescript '>=4.8.4 <6.1.0'; @typescript/typescript6 latest 6.0.2. Hands-on on box (8 vCPU/15 GB, Node 24.21.0): Hono main 5f36607 (2026-10-05T18:29:52+09:00 = 14:59 IST), pnpm 12.6.0 frozen lockfile; tsc -p <cfg> --noEmit, tsbuildinfo deleted each run, 3 runs. tsconfig.build.json 363 files: TS6 3.02/2.95/3.09 s (RSS ~524 MB) vs TS7 0.70/0.65/0.63 s (~337 MB). tsconfig.spec.json 906 files: TS6 9.59/10.37/10.23 s (~1,032 MB) vs TS7 1.41/1.45/1.41 s (~718 MB). TS7 spec flags: --checkers 8 1.41/1.53/1.46 s (~872 MB); --checkers 1 2.74/2.86/2.52 s (~552 MB); --singleThreaded 2.94/3.00/2.83 s (~552 MB). Incremental no-change rerun: TS7 0.23 s vs TS6 1.50 s. TS7 spec: 4 diagnostics (2x TS2578 + 2x TS2769, src/hono.test.ts 3416/3419, 3547/3550); with directives removed TS6 reports TS2769 at 3417:7/3548:7, TS7 at 3419:5/3550:5. Legacy tsconfig fixture: TS6 TS5107/TS5101 deprecations; TS7 TS5108/TS5102 removed + TS5090 non-relative paths. No ShopperCove production code changed. No affiliate.

Explore the product

Untested by us, and no traffic result is guaranteed. Check the live offer and refund terms first.

AI Traffic Secrets for AI-era SEO

See AI Traffic Secrets details

Ready Client Sites for prebuilt websites

See Ready Client Sites details

TypeScript 7: Is tsc Really 7x Faster?

5 October 20267 min read

Summary

What I tested

Machine: 8 vCPU / 15 GB RAM Linux cloud box (kernel 6.12). Node 24.21.0 runs TypeScript 6; TypeScript 7 is a native Go binary.
Compilers: typescript@6.0.3 and typescript@7.0.2, installed side by side with npm aliases.
Codebase: Hono main at commit 5f36607 (5 Oct 2026, 14:59 IST), package version 4.13.13, dependencies from its lockfile via pnpm 12.6.0.
Command: tsc -p <config> --noEmit, three runs per cell, median reported. Peak memory is max RSS from getrusage.
One surprise: Hono's base config sets composite: true, so a leftover .tsbuildinfo turns the next run into an incremental check. My first pass showed TypeScript 7 at 0.23 s for that reason. I deleted the build info before every timed run below.
Not tested: editor and LSP latency, --build with project references, emit, watch mode, Windows or macOS.

How much faster is TypeScript 7 on a real project?

Hono config	Files	TS 6.0.3 median	TS 7.0.2 median	Speedup	Peak RSS (6 → 7)
`tsconfig.build.json` (src only)	363	3.02 s (3.02 / 2.95 / 3.09)	0.65 s (0.70 / 0.65 / 0.63)	4.6x	524 MB → 337 MB
`tsconfig.spec.json` (src + tests)	906	10.23 s (9.59 / 10.37 / 10.23)	1.41 s (1.41 / 1.45 / 1.41)	7.3x	1,032 MB → 718 MB

With the build info left in place, a no-change second run took 0.23 s on 7.0.2 and 1.50 s on 6.0.3 (one run each).

Does --checkers help on an 8-core machine?

TypeScript 7 runs 4 type-checker workers by default. I timed the 906-file config with the new flags:

TS 7.0.2 flag	Median	Peak RSS
default (4 checkers)	1.41 s	718 MB
`--checkers 8`	1.46 s (1.41 / 1.53 / 1.46)	872 MB
`--checkers 1`	2.74 s (2.74 / 2.86 / 2.52)	552 MB
`--singleThreaded`	2.94 s (2.94 / 3.00 / 2.83)	552 MB

Will TypeScript 7 break my build?

I hit two kinds of breakage.

How do I upgrade without breaking lint?

Get clean on TypeScript 6.0 with no ignoreDeprecations setting. Add rootDir and an explicit types list if you relied on the old defaults (7.0 defaults types to []).
Use the alias setup from the announcement so tsc is 7.0 and every tool importing typescript still gets 6.0:

{
  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  }
}

Run tsc --noEmit (7.0) and tsc6 --noEmit (6.0) in CI for a week and diff the output. Look for moved @ts-expect-error targets first.
Pin --checkers in CI.
In VS Code, install the TypeScript 7 extension. For Vue, Svelte, Astro or MDX workspaces, run "Disable TypeScript 7 Language Server" until 7.1 ships its API. The same holds if you are on the Astro 7.3 preview or a SvelteKit 3 migration.

Should you upgrade to TypeScript 7?

Your setup	My call
Plain TS or React app, `bundler` or `nodenext` resolution, clean on 6.0	Upgrade CLI and editor now
Type-aware typescript-eslint	Upgrade `tsc` through the alias; keep 6.0 for lint
Angular	TS 7 for CLI checks, 6.0 for template type-checking in the editor
Vue, Svelte, Astro, MDX	CLI checks only where possible; editor stays on 6.0 until 7.1
`target: es5`, `baseUrl`, `node10` resolution	Fix the config on 6.0 first
Custom transformers or loaders that import the `typescript` API	Wait for 7.1

How this was made: I ran every command above on the ShopperCove test box and kept the raw output; the write-up was drafted with AI help and checked="true" against that output.