Is TypeScript 7 Really 10x Faster? A Real Next.js 16 Migration

Tested and reviewed July 24, 2026. TypeScript 7 shipped with a “10x faster” headline. Instead of repeating the release announcement, I compared TypeScript 5.9.3 and 7.0.2 with the same command on the Next.js 16 project that powers this site.

The difference was clear: the median tsc --noEmit check fell from 4.79 seconds to 0.45 seconds. That is about a 10.6x speedup and an approximately 90.6% reduction in elapsed time for this repository. The second half of the migration mattered more than the number, though. A direct single-package upgrade failed because TypeScript 7 no longer ships the programmatic compiler API. The working setup had to run the TypeScript 7 CLI alongside the TypeScript 6 compatibility package.

The short answer

Question	What happened in this project
Is TypeScript 7 actually faster?	Yes. The five-run CLI typecheck median dropped from 4.79 seconds to 0.45 seconds: roughly 10.6x.
Does that mean the entire Next.js production build became 10.6x faster?	No. The benchmark covers only tsc --noEmit --incremental false.
Did a direct npm install -D typescript upgrade work?	No. Tests and tooling that require the old compiler API broke under the single-package setup.
What worked?	TypeScript 7.0.2 for the CLI, with the TypeScript 6 compatibility package for API consumers.
Did the project still pass its checks?	Yes: lint, all 49 tests, the production build, and local smoke tests for four key routes passed.

Why was TypeScript rebuilt in Go?

TypeScript 6 and earlier used a compiler written in TypeScript and executed as JavaScript. TypeScript 7 moves to a new Go codebase. The team describes it as a faithful port that preserves the old compiler’s structure and logic where possible, rather than an unconstrained redesign of type-checking semantics.

The official TypeScript 7 announcement attributes the performance gain to native code, shared-memory multithreading, and additional optimizations. Microsoft’s full-build measurements range from 7.7x to 11.9x: VS Code falls from 125.7 to 10.6 seconds, Sentry from 139.8 to 15.7 seconds, and Playwright from 12.8 to 1.47 seconds.

Those results are strong, but they are not a promise for every project. Repository size, type-graph shape, CPU cores, storage, CI limits, and compiler options all affect the result. TypeScript 7 uses four checker workers by default. More workers may help large projects, while constrained CI runners may need fewer workers to avoid memory overhead.

The project and test environment

I ran the comparison on the open-source codebase for this site. It started on Next.js 16.2.10 and TypeScript 5.9.3. The repository uses React 19 and type-checks the application, API routes, admin interface, and test files together.

Component	Value
Machine	Apple M4 Max, 16 cores, 48 GB memory
Operating system	macOS 26.2
Node.js / npm	Node.js 24.18.0 / npm 11.12.1
Framework	Next.js 16.2.10 using the Webpack production-build path
Compilers compared	TypeScript 5.9.3 and TypeScript 7.0.2
Command	tsc --noEmit --incremental false

The --incremental false choice was deliberate. This project normally enables incremental checks and writes tsconfig.tsbuildinfo. I disabled incremental state during the benchmark so neither compiler benefited from its own older cache file. Every run used the same worktree, dependency graph, and Node 24.18.0 binary. TypeScript 5.9.3 was installed in an isolated temporary directory so the benchmark did not rewrite the migrated project dependencies.

repeat 5 {
  /usr/bin/time -p ./node_modules/.bin/tsc \
    --noEmit \
    --incremental false
}

Result: roughly 10.6x faster type-checking

Each compiler ran exactly five times. TypeScript 5.9.3 completed in 5.41, 4.73, 4.77, 4.82, and 4.79 seconds. TypeScript 7.0.2 completed in 0.51, 0.45, 0.44, 0.42, and 0.46 seconds.

Compiler	Five runs	Range	Median
TypeScript 5.9.3	5.41 / 4.73 / 4.77 / 4.82 / 4.79s	4.73–5.41s	4.79s
TypeScript 7.0.2	0.51 / 0.45 / 0.44 / 0.42 / 0.46s	0.42–0.51s	0.45s

Comparing the five-run medians gives roughly 4.79 / 0.45 = 10.6. The reduction in elapsed time is approximately (4.79 - 0.45) / 4.79 = 90.6%.

That local 10.6x result sits inside Microsoft’s typical 8–12x range, but the measurements are not equivalent. Microsoft mainly compares TypeScript 6 and 7 full builds on very large codebases. This test compares 5.9 with 7 on a medium-sized Next.js project, without emit or incremental cache. Treating the numbers as rows in the same benchmark table would be misleading.

What this benchmark does not prove

• It does not show that the full Next.js production build is 10.6x faster.
• It does not measure editor completion or time to first diagnostic.
• It does not measure CI time or memory consumption.
• It does not imply every TypeScript project will see the same ratio.
• It does not prove that every framework tool is already API-compatible with TypeScript 7.

It shows something narrower and useful: on the same machine and configuration, the standalone TypeScript 7 CLI completed a project-wide typecheck for this repository about 10.6x faster.

Why did the direct upgrade fail?

The first attempt replaced TypeScript 5.9.3 with 7.0.2 in the usual way:

npm install --save-dev typescript@^7.0.2
npm run typecheck

The compiler started, but the project did not pass. Several tests import the typescript package directly to transpile source modules and relied on these APIs:

• transpileModule
• ModuleKind
• ScriptTarget

TypeScript 7 does not ship a programmatic JavaScript API, so the check reported TS2339 errors for those missing names. The typescript-eslint dependency graph also marked TypeScript 7 as outside its accepted peer range.

This is not an undocumented regression. The official announcement states that TypeScript 7.0 has no API and that a new, different API is planned for 7.1. Tools that embed the compiler may still need the TypeScript 6 API. The TypeScript team published @typescript/typescript6 specifically for this transition.

The working setup: TypeScript 7 and 6 side by side

I used the npm alias arrangement recommended by the TypeScript team:

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

The responsibilities are now explicit:

• The tsc command runs the native TypeScript 7.0.2 compiler.
• ESLint, Next.js, and test helpers that import typescript receive the TypeScript 6 compatibility API.
• The tsc6 command keeps the legacy compiler path available when needed.

The project has therefore adopted TypeScript 7 for CLI type-checking while API-dependent parts of the ecosystem use a TypeScript 6 bridge. That distinction matters. It is accurate to say TypeScript 7 is installed and running; it would be inaccurate to say the entire toolchain now uses only TypeScript 7.

The exact package change is available in the public migration commit.

What passed after the migration?

A fast compiler is not useful if the rest of the project becomes unreliable. After applying the side-by-side setup, I reran the normal project gates:

• Typecheck: passed with TypeScript 7.0.2.
• Lint: ESLint completed across the repository without errors.
• Tests: all 49 tests passed.
• Production build: the Next.js 16.2.10 build completed and generated 61 static pages.
• Local smoke test: the home, blog, contact, and open-source routes returned HTTP 200 with no page-level runtime errors.

Next.js reported 11.1 seconds for its own “Running TypeScript” production-build phase. That number should not be compared directly with the 0.45-second standalone CLI result. Next.js checks generated framework types and uses the TypeScript 6 compatibility API path. This is exactly why the conclusion is not “the Next.js build became 10x faster”; it is “the standalone project-wide typecheck became 10.6x faster.”

A migration checklist for TypeScript 7

1. Record a baseline first. Use the same commit, machine, Node version, and compiler flags for multiple runs.
2. Control incremental state. Use --incremental false for a cold compiler comparison, or remove the build-info file deliberately. Keep normal cache state when measuring everyday workflows.
3. Find compiler API consumers. If the project contains import ts from "typescript", transpileModule, createProgram, or language-service calls, a direct single-package upgrade may not be enough.
4. Resolve TypeScript 6 deprecations. TypeScript 7 turns removed settings such as target: es5, moduleResolution: node10, baseUrl, downlevelIteration, and legacy module targets into hard errors.
5. Review the new rootDir and types defaults. Projects that silently rely on global @types packages may need explicit configuration.
6. Test the CLI and framework paths separately. tsc --noEmit may pass while a framework build uses a different integration API.
7. Run lint, tests, a production build, and a runtime smoke test. Do not stop at the compiler’s exit code.

This project already had a migration-friendly tsconfig.json: strict was enabled, module was esnext, moduleResolution was bundler, and path entries were relative to the project root. It did not use the removed baseUrl or legacy Node resolution modes.

Who should not upgrade directly yet?

The TypeScript team notes that workflows for Vue, MDX, Astro, Svelte, and Angular may not yet get the full TypeScript 7 experience. The issue is not TypeScript syntax; it is the lack of a stable programmatic API in 7.0 for tools that embed the compiler or language service.

A side-by-side setup—or waiting for the new API—is safer when:

• Your framework or template compiler imports the TypeScript API directly.
• You maintain custom transformers, AST tooling, or code built on ts.createProgram.
• Your ESLint or editor plugins do not yet accept TypeScript 7 in their peer range.
• Your CI runners have limited CPU or memory and you have not tested multi-checker behavior.
• Your TypeScript 6 setup still hides removed options behind ignoreDeprecations.

Final verdict: is it worth moving?

For this repository, yes. tsc --noEmit is a frequent development and CI gate, and reducing a six-second check to under one second materially tightens the feedback loop. Lint, all 49 tests, the production build, and local routes continued to work after the migration.

The correct migration was not “change the version and move on,” however. The fast native CLI is useful today, while API-dependent tools still need a TypeScript 6 bridge. This arrangement should be revisited when TypeScript 7.1 delivers the new API.

The most accurate summary of the experiment is: TypeScript 7 made the standalone typecheck in this Next.js 16 project about 10.6x faster, but a direct single-package upgrade did not work.

Primary sources and reproducibility

• The TypeScript team: Announcing TypeScript 7.0 — performance, parallelism, side-by-side installation, and API limits
• The TypeScript team: Announcing TypeScript 6.0 — deprecations and transition changes before 7.0
• TypeScript 7 change log — intentional differences from TypeScript 6
• The open-source Go codebase for TypeScript 7
• The TypeScript 7 migration commit described in this article

This benchmark covers one machine and one repository. Timings are wall-clock measurements; memory usage, editor language-server latency, and CI performance were not measured. Results were recorded on July 24, 2026 with TypeScript 5.9.3 and 7.0.2.