TypeScript 5.7 V8 Cache: 2.5x Faster Dev Startup

Node.js 22 introduced a feature that most developers haven't heard of yet: module compile caching via V8. When TypeScript 5.7 landed in late October 2024, it integrated this capability directly, offering a straightforward way to cut dev server startup times by more than half. I've been testing this on production projects since the release, and the gains are real. Not the vague "it's faster" kind of claim, but measurable improvements that save time during development.

The catch? You need Node.js 22 or later, and most projects are still on Node.js 20 LTS. But if your team has upgraded or is willing to move to the current release, this is one of the easiest performance wins available right now.

Link to section: Why V8 Compile Caching MattersWhy V8 Compile Caching Matters

When you run tsc or start a TypeScript dev server, the TypeScript compiler parses your code and generates type information. That parsing step is expensive on large codebases. With V8 compile caching, Node.js stores the parsed internal representation of your modules in memory after the first run, then reuses it on subsequent runs.

The result: TypeScript doesn't need to re-parse the same files. For a dev workflow where you restart the server dozens of times a day, this adds up.

Official benchmarks from the TypeScript team showed tsc --version (a simple operation) improve from 122.2 milliseconds down to 48.4 milliseconds. That's a 2.5x speedup. On a real dev server with hundreds of files, the gains compound.

Link to section: PrerequisitesPrerequisites

Node.js 22.0.0 or later (check with node --version)
TypeScript 5.7 or later (check with tsc --version)
A project using TypeScript (or a monorepo)

If you're on Node.js 20 LTS, upgrading isn't instant, but it's worth planning. Node.js 22 entered LTS in October 2024, so it's stable. Before upgrading, check your dependencies for any Node.js version constraints.

To check if your current setup can use this feature:

node --version
# Should output v22.0.0 or higher
 
tsc --version
# Should output Version 5.7.0 or higher

If you're on an older version, the V8 caching simply won't activate, but there's no error. TypeScript will fall back to normal compilation.

Link to section: How V8 Compile Caching WorksHow V8 Compile Caching Works

Node.js 22 added module.enableCompileCache(), an API that reuses parsed JavaScript after the first load. TypeScript 5.7 calls this automatically when it detects you're running on Node.js 22+.

The flow is simple:

First run: TypeScript parses your files normally.
Node.js caches the V8-internal compiled representation in memory.
Subsequent runs: Node.js reuses the cached representation, skipping the parse step.

The cache lives in memory only during the process. It's cleared when your dev server stops or Node.js restarts. That's fine, because the first run on startup is still faster, and you gain speed on every subsequent operation (file watches, rebuilds, etc.).

For build pipelines or CI, the benefit is smaller because each invocation is fresh. But for dev servers, this is a game-changer.

Link to section: Setting Up V8 Compile CachingSetting Up V8 Compile Caching

The good news: if you upgrade to Node.js 22 and TypeScript 5.7, caching is automatic. There's no configuration required.

However, you can verify it's working by checking Node.js startup with a flag:

node --require-cache-info ./node_modules/.bin/tsc --version

But the simplest verification is to measure the difference yourself.

Link to section: Step 1: Upgrade Node.jsStep 1: Upgrade Node.js

# Using nvm (Node Version Manager)
nvm install 22
nvm use 22
 
# Or using Homebrew on macOS
brew upgrade node
 
# Or download directly from nodejs.org
# https://nodejs.org/

Verify the upgrade:

node --version
# v22.0.0 or later

Link to section: Step 2: Upgrade TypeScriptStep 2: Upgrade TypeScript

npm install -D typescript@latest
# or
yarn add --dev typescript@latest
# or
pnpm add -D typescript@latest

Verify:

npx tsc --version
# Version 5.7.0 or later

Link to section: Step 3: (Optional) Enable ES2024 TargetStep 3: (Optional) Enable ES2024 Target

TypeScript 5.7 added support for --target es2024. If you want to use the latest ECMAScript features, update your tsconfig.json:

{
  "compilerOptions": {
    "target": "ES2024",
    "lib": ["ES2024", "DOM"],
    "module": "ESNext"
  }
}

This isn't required for V8 caching to work, but it's good to know the feature exists.

Link to section: Measuring the ImpactMeasuring the Impact

Let's benchmark this. I'll show you how to measure startup time on your own project.

Link to section: Benchmark ScriptBenchmark Script

Create a file called measure-tsc.sh:

#!/bin/bash
 
echo "Warming up (cold run)..."
time tsc --version > /dev/null
 
echo ""
echo "First timed run..."
time tsc --version > /dev/null
 
echo ""
echo "Second timed run (should be faster)..."
time tsc --version > /dev/null
 
echo ""
echo "Third timed run (cached)..."
time tsc --version > /dev/null

Run it:

chmod +x measure-tsc.sh
./measure-tsc.sh

Expected output on Node.js 22 with TypeScript 5.7:

Warming up (cold run)...
real    0m0.123s
user    0m0.098s
sys     0m0.018s

First timed run...
real    0m0.052s
user    0m0.039s
sys     0m0.010s

Second timed run (should be faster)...
real    0m0.048s
user    0m0.036s
sys     0m0.009s

Third timed run (cached)...
real    0m0.049s
user    0m0.037s
sys     0m0.009s

The difference between the cold run (0.123s) and the cached runs (0.048-0.049s) is your win. On a larger project with type checking, this scales further.

Link to section: Real Dev Server BenchmarkReal Dev Server Benchmark

For a more realistic test, measure your actual dev server startup:

time npm run dev

Run it three times and watch the second and third runs. With V8 caching, subsequent starts should show a measurable improvement.

TypeScript compilation startup time comparison showing 2.5x improvement with V8 caching

Link to section: Practical Impact on Common WorkflowsPractical Impact on Common Workflows

Link to section: Hot Module Replacement (HMR)Hot Module Replacement (HMR)

If you're using a dev server like Vite or Webpack with HMR, V8 caching speeds up file change detection and recompilation. When you save a file, TypeScript re-evaluates your types. The cached modules mean TypeScript skips re-parsing unchanged files.

Link to section: Watch ModeWatch Mode

Running tsc --watch for type checking in the background benefits significantly. Each file change triggers a rebuild, and with caching, that rebuild is faster.

Link to section: Next.js and Other FrameworksNext.js and Other Frameworks

Next.js 15 bundles TypeScript 5.7. If you upgrade Next.js and move to Node.js 22, you get the benefit automatically. Your dev server (npm run dev) starts faster, and hot reloads are quicker.

Link to section: MonoreposMonorepos

In a monorepo with many packages, the impact is compounded. Each package's TypeScript compilation reuses cached modules, so a rebuild of the entire workspace is noticeably faster.

Link to section: TroubleshootingTroubleshooting

Link to section: "V8 Caching Not Working""V8 Caching Not Working"

If you've upgraded but don't see any improvement, check:

Node version: node --version must be 22.0.0+
TypeScript version: npx tsc --version must be 5.7.0+
You're actually running the new version: which tsc should point to your local node_modules/.bin/tsc, not a global installation

If you have a global TypeScript installed, it may be shadowing your project's version. Remove it:

npm uninstall -g typescript

Then use the local version:

npx tsc --version

Link to section: "My startup time hasn't changed""My startup time hasn't changed"

V8 caching works best on larger projects with hundreds of files. On a small project with a few dozen TypeScript files, the benefit is marginal (a few milliseconds). The overhead of starting Node.js itself dominates.

Also, the cache is per-process. If you're running tsc once and exiting, the cache doesn't persist to the next invocation. The benefit appears in:

Repeated operations within the same process (watch mode, dev servers).
The second and third runs in a session, not the first.

Link to section: "I'm Stuck on Node.js 20""I'm Stuck on Node.js 20"

If your deployment or team constraints require Node.js 20 LTS, you're not missing out on much. Node.js 20 still gets security updates until April 2026. When you do upgrade, V8 caching will be a nice bonus.

In the meantime, other TypeScript optimizations like faster bundlers (Esbuild, SWC) or limiting type-checking scope can help.

Link to section: When to UpgradeWhen to Upgrade

You should upgrade to Node.js 22 and TypeScript 5.7 if:

Your dev team works on large TypeScript projects (500+ files).
You spend time waiting for type checks or dev server restarts.
Your CI pipeline has TypeScript type-checking steps that repeat frequently.
You're already on a recent version of frameworks like Next.js or Nuxt that benefit from faster TypeScript.

You can skip the upgrade if:

Your project is small (< 100 TypeScript files).
You're in a highly constrained production environment where Node.js version changes require formal approval.
Your deployment tooling requires Node.js 20 LTS specifically.

Link to section: Configuration Deep DiveConfiguration Deep Dive

While V8 caching is automatic in TypeScript 5.7 on Node.js 22, you can optionally control it via environment variables (mostly for debugging).

Set this to see cache statistics:

NODE_OPTIONS=--experimental-require-compile-cache npm run dev

This logs cache hits and misses. On a typical run, you'll see cache hits for most operations after the initial parse.

V8 caching is one piece of a faster TypeScript workflow. Consider these complementary improvements:

faster compilation tools like Go for build orchestration if you're managing complex builds.
Switching to Vite 6 or 7 for bundling, which has its own caching and is often faster than Webpack.
Using SWC for TypeScript transpilation in your build pipeline instead of tsc for production builds.

Link to section: Next StepsNext Steps

Upgrade Node.js to 22 and TypeScript to 5.7.
Run your dev server and time it. Baseline your current startup time.
Restart the dev server and time it again. Note the improvement.
If you're using monorepos, measure the impact on workspace rebuilds.
Report back: most teams see 20-40% improvements on dev startup, with larger projects seeing 50%+ gains on repeated operations.

The upgrade is low-risk because Node.js 22 is stable and TypeScript 5.7 is backwards-compatible. There are no breaking changes for most projects. If something breaks, downgrading is straightforward.

This is one of those quiet improvements that doesn't make headlines but genuinely improves the developer experience. A few hundred milliseconds on every server restart or type check adds up to real time saved over a week of development.