Vite 7 ships next month. The headline is the new dev server, which is a near-complete rewrite of the module graph and HMR pipeline. Here's the why and the how.

The old graph couldn't scale

Vite 4 and 5 used a flat module map keyed by URL. It worked beautifully for projects under 5k modules. Above that, two pain points appeared:

1. Cold-start times grew superlinearly
2. HMR boundaries got fuzzy in monorepos with shared deps

The fix was to move to a layered graph: a resolver layer that computes module identity once, and a transform layer that caches AST passes. The two layers communicate via a stable handle.

What changed in your code

Almost nothing. The plugin API stays compatible. The one breaking change is in the resolveId hook — it now returns a structured object instead of a string:

// Before (Vite 6)
resolveId(id) {
  return '/abs/path/to/' + id
}

// After (Vite 7)
resolveId(id) {
  return { id: '/abs/path/to/' + id, external: false }
}

Most plugin authors won't notice — we're shipping a codemod that handles the migration automatically. Run it with npx vite-codemod 7.

Performance numbers

On a 12k-module monorepo we saw:

• Cold start: 14.2s → 3.8s (3.7x)
• Warm reload: 280ms → 95ms (2.9x)
• Memory at idle: 480MB → 220MB

On smaller projects the wins are less dramatic but still meaningful — expect 30-40% on cold start, 20-30% on HMR.

Try it now

npm install vite@next and report any plugin compatibility issues on the GitHub repo. We're prioritizing fixes through the RC window.