Vite 6 im Detail: ESM Module Federation und Performance-Optimierung

46 Sekunden.

So lange wartete das Linear-Team bei jedem Build. Eine Zeile Code ändern, neu bauen – wieder 46 Sekunden. Ende 2024 stiegen sie auf Vite 6 und aktivierten Rolldown. Die Build-Zeit fiel auf 6 Sekunden.

Als ich die Zahl las, war ich skeptisch. Zehnfach schneller? Erst nach einem Test im eigenen Projekt glaubte ich: Die Zahlen stimmen.

Vite 6 ist kein kleines Config-Update. Die Environment API verändert Multi-Environment-Builds grundlegend, Rolldown vereinheitlicht Dev- und Prod-Bundling, und ESM Module Federation bekommt offizielle Unterstützung.

Für normale Projekte spüren Sie das vielleicht kaum. Wer große Frontend-Apps oder Micro-Frontends betreibt – oder genug hat von „lokal ok, Production kaputt“ – sollte weiterlesen.

Kapitel 1: Vite-6-Kernneuerungen im Überblick

1.1 Environment API: neues Paradigma für Multi-Environment

Die Environment API ist die größte Architekturänderung in Vite 6 – und die meisten Projekte werden sie nie anfassen.

Früher kannte Vite standardmäßig client und ssr. Für Cloudflare Workers, Deno oder andere Edge-Runtimes mussten Sie selbst basteln. Framework-Autoren schrieben dafür oft Workarounds.

Die Environment API formalisiert diesen Prozess. So könnte die Konfiguration aussehen:

// vite.config.ts
export default defineConfig({
  environments: {
    client: {
      // Browser-Umgebung
      build: {
        outDir: 'dist/client'
      }
    },
    ssr: {
      // Node.js SSR-Umgebung
      build: {
        outDir: 'dist/server'
      }
    },
    edge: {
      // Edge-Runtime (z. B. Cloudflare Workers)
      resolve: {
        conditions: ['worker']
      },
      build: {
        outDir: 'dist/edge'
      }
    }
  }
})

Brauchen Sie das? Wahrscheinlich nicht. Die API ist vor allem für Framework-Autoren – Nuxt, SvelteKit, Astro können Deployments eleganter abbilden.

Als SPA- oder MPA-Projekt ändert sich für Sie nichts. Vite bleibt abwärtskompatibel.

Indirekt profitieren Sie trotzdem: Nuxt deployt einfacher auf Cloudflare Workers, Astro läuft auf Deno Deploy – Möglichkeiten, die die Environment API ermöglicht.

1.2 Node.js-Unterstützung und Migrationsfolgen

Vite 6 unterstützt Node.js 18, 20 und 22+. Node.js 21 entfällt – eine LTS-Zwischenversion, die ohnehin selten in Produktion lief.

Noch auf Node.js 16? Zeit zum Upgrade. Minimum ist 18.18.0 – dort kamen Features, die Vite braucht.

Beim Migrieren beachten:

• resolve.conditions hat neue Defaults: von ['module', 'browser', 'jsnext:main', 'jsnext'] zu ['module', 'browser', 'jsnext:main', 'jsnext', 'import']. Manuelle Einstellungen prüfen.
• Bei Deno, Bun oder anderen Nicht-Standard-Umgebungen ggf. resolve.conditions explizit setzen.

Bei den meisten Projekten reicht npm install vite@latest. Drei meiner Projekte: eine Zeile, fertig.

1.3 Weitere wichtige Änderungen

Neben der Environment API gibt es weitere Updates:

Sass Modern API standardmäßig aktiv. Früher nutzte Vite die Legacy-API. Bei Sass-Fehlern können Sie zurückschalten:

export default defineConfig({
  css: {
    preprocessorOptions: {
      scss: {
        api: 'legacy' // Bei Problemen mit Modern API
      }
    }
  }
})

JSON-Stringify-Optimierung. Statische JSON-Objekte werden per JSON.stringify() vorverarbeitet – kleinere Bundles, besonders bei großen Config-Dateien.

Railway - Moderne Deployment-Plattform, ohne DevOps-Aufwand, in Minuten live

Jetzt starten →Anzeige

Worker-Optionen. worker.format default ist jetzt 'es' statt 'iife'. Worker und Hauptcode teilen dasselbe Modulsystem.

Im Alltag merken Sie wenig – außer bei Sass: Ein Projekt mit eigenen Sass-Funktionen brach wegen der API-Umstellung. Halber Tag Debugging.

Kapitel 2: Rolldown-Integration und Performance-Sprung

2.1 Warum Vite Rolldown braucht

Vite 5 nutzt esbuild in Dev und Rollup in Prod – zwei Bundler.

Dev ist schnell (esbuild in Go). Prod wechselt zu Rollup (JavaScript) – spürbar langsamer.

Schlimmer: unterschiedliche Plugin-APIs. Dev-Plugins funktionieren in Prod oft nicht – und umgekehrt. „Lokal ok, Build kaputt“ ist die Folge.

Rolldown soll das lösen.

Rolldown ist ein in Rust geschriebener Rollup-Ersatz mit kompatibler Plugin-API – laut offiziellen Benchmarks 10–30× schneller als Rollup, nahe esbuild-Geschwindigkeit.

Vite will Rollup durch Rolldown ersetzen und Dev/Prod vereinheitlichen. Gleiche Plugins, weniger Überraschungen beim Build.

2.2 Rolldown-Performance im Vergleich

Zahlen statt Versprechen – aus der Vite-8-Beta-Ankündigung:

Quelle: Vite-8-Beta-Blog.

Erwartete Vorteile von Full Bundle Mode:

• Dev-Server-Start etwa 3× schneller
• Full-Page-Reload etwa 40 % schneller
• 10× weniger Netzwerk-Requests

Full Bundle Mode bundelt in Dev alles – statt pro Request eine Datei zu kompilieren. Schnellerer Start und Refresh, erster Start etwas langsamer.

Die Marketing-Zahlen klingen extrem. Mein Monorepo mit 3.000+ Dateien: Vite 5 Build 90 s, mit Rolldown 12 s – etwa 7×. Nicht ganz 10×, aber deutlich.

2.3 Rolldown aktivieren (rolldown-vite)

Zwei Wege:

Variante 1: rolldown-vite-Paket

vite durch rolldown-vite ersetzen:

// package.json
{
  "dependencies": {
    "rolldown-vite": "latest"
  }
}

In vite.config.ts:

export default defineConfig({
  build: {
    rolldown: true
  }
})

Schneller Einstieg; Plugin-Kompatibilität meist gut.

Variante 2: Vite 8 Stable abwarten

Vite 8 Beta integriert Rolldown standardmäßig:

npm install vite@8

Stand Dezember 2025 noch Beta. Produktion: Stable abwarten oder rolldown-vite in Testprojekten.

Offizielle Migrations-Empfehlung:

1. Mit rolldown-vite Plugin-Kompatibilität testen
2. Bei Erfolg auf Vite 8 Stable upgraden
3. Bei Inkompatibilität Rolldown vorübergehend deaktivieren, klassisches Rollup nutzen

2.4 advancedChunks statt manualChunks

Rolldown bringt advancedChunks – flexibler als Rollups manualChunks.

Rollup (alt):

// Rollup manualChunks (alt)
export default defineConfig({
  build: {
    rollupOptions: {
      output: {
        manualChunks: {
          'vendor': ['react', 'react-dom', 'lodash'],
          'utils': ['axios', 'dayjs']
        }
      }
    }
  }
})

Problem: Jede Abhängigkeit manuell zuordnen. Neue Pakete landen sonst im Main-Chunk.

Rolldown advancedChunks mit Gruppen:

Vultr - Hochleistungs-NVMe-Cloud-Server mit 32 Standorten weltweit, Docker per Klick

Preise ansehen →Anzeige

// Rolldown advancedChunks (neu)
export default defineConfig({
  build: {
    advancedChunks: {
      groups: [
        {
          name: 'vendor-react',
          test: /react|react-dom/,
          priority: 10
        },
        {
          name: 'vendor-utils',
          test: /lodash|axios|dayjs/,
          priority: 5
        },
        {
          name: 'vendor-shared',
          test: /[\\/]node_modules[\\/]/,
          priority: 1
        }
      ]
    }
  }
})

Höhere Priorität zuerst; Rest über Catch-all-Gruppe. Regex statt manueller Listen.

Bonus: doppelte Abhängigkeiten in mehreren Chunks werden in Shared Chunks extrahiert – in Monorepos sehr hilfreich.

Kapitel 3: ESM Module Federation

3.1 Community-Lösung: vite-plugin-federation

Module Federation ist Webpack-5-Kernfeature: Teams liefern unabhängige „Föderationen“, die Code teilen. Vite unterstützt das nativ nicht.

Die Community nutzt vite-plugin-federation – 3.000+ GitHub Stars, reifeste Vite-Lösung.

Konfiguration ähnlich Webpack:

// vite.config.ts - Host-App
import federation from '@originjs/vite-plugin-federation'

export default defineConfig({
  plugins: [
    federation({
      name: 'host-app',
      remotes: {
        remoteApp: 'http://localhost:5001/assets/remoteEntry.js'
      },
      shared: ['react', 'react-dom']
    })
  ]
})

// vite.config.ts - Remote-App
import federation from '@originjs/vite-plugin-federation'

export default defineConfig({
  plugins: [
    federation({
      name: 'remote-app',
      filename: 'remoteEntry.js',
      exposes: {
        './Button': './src/components/Button',
        './Header': './src/components/Header'
      },
      shared: ['react', 'react-dom']
    })
  ]
})

Host nutzt remotes, Remote exposes. shared vermeidet doppeltes Bundling.

Vorteile:

• Webpack-Module-Federation-kompatibel
• Einfache Konfiguration, bekannte Konzepte
• Reife Community, viele Praxisberichte

Nachteile:

• Kein Vite-Native-Feature, Plugin-Risiken
• Prod-Build über Rollup, nicht identisch zu Webpack
• Debugging bei Cross-Project-Imports aufwendig

3.2 Rolldown-native Module Federation

Rolldown implementiert native Module-Federation-Unterstützung.

Beispiel-Repo rolldown-vite-module-federation-example – noch RC, nicht für Produktion empfohlen.

Vorteile:

• Webpack-5-Module-Federation-API-kompatibel
• Einheitliches Bundling, kein Vite/Webpack-Wechsel
• Rolldown-Performance

Konfiguration (RC, kann sich ändern):

// Rolldown Module Federation (RC)
export default defineConfig({
  build: {
    moduleFederation: {
      name: 'host-app',
      remotes: {
        remoteApp: 'remoteApp@http://localhost:5001/remoteEntry.js'
      },
      exposes: {
        './Component': './src/Component.tsx'
      },
      shared: {
        react: { singleton: true },
        reactDom: { singleton: true }
      }
    }
  }
})

Ähnlich vite-plugin-federation, näher an Webpack. singleton: true lädt nur eine Version.

3.3 Welche Lösung wählen?

Produktion: vite-plugin-federation – stabil, Community-Erfahrung.

Neue oder experimentelle Projekte: Rolldown-native Lösung, wenn Sie ohnehin Rolldown nutzen – RC-Risiko einkalkulieren.

Webpack-Interop: Beide funktionieren.

Module Federation ist kein Allheilmittel. Sinnvoll bei großen Multi-Team-Projekten und unabhängig deploybaren Micro-Frontends. Sonst: Monorepo oder npm-Pakete reichen oft.

Kapitel 4: Performance-Best-Practices

Vite 6 ist schon schnell. Bei großen Projekten – tausende Dateien, viele Dependencies – lohnt Feintuning.

4.1 Häufige Dateien vorwärmen (warmup)

Der Dev-Server wärmt standardmäßig Entry und direkte Abhängigkeiten vor. Sie können mehr angeben:

export default defineConfig({
  server: {
    warmup: {
      clientFiles: [
        './src/main.tsx',
        './src/pages/Home.tsx',
        './src/pages/Dashboard.tsx'
      ]
    }
  }
})

Vorteil: Diese Dateien sind kompiliert, bevor Sie den Browser öffnen – kein spürbarer Delay beim ersten Besuch.

Sinnvoll für:

• Entry (Default)
• häufig besuchte Seiten
• große Library-Entries wie lodash-es

Nicht zu viel vorwärmen – erhöht Startzeit. 5–10 Dateien reichen meist.

4.2 Barrel Files vermeiden

Barrel Files re-exportieren viele Module:

// ❌ Barrel File – vermeiden
export { Button } from './Button'
export { Input } from './Input'
export { Modal } from './Modal'
export { Table } from './Table'

Sauberer Import:

🔥 Verschwende keine Monate für ungenutzte Produkte! Teste deine SaaS-Nutzenversprechen mit Adsterra bei kleinem Budget →

Jetzt testen →Anzeige

import { Button, Input, Modal } from './components'

Aber Vite lädt zuerst das Barrel, dann jedes Modul – Request-Waterfall, Sekunden Verzögerung bei großen Barrels.

Besser direkt importieren:

// ✅ Direkte Imports
import Button from './components/Button'
import Input from './components/Input'

Parallele Loads, kein Waterfall.

Mit Rolldown Full Bundle Mode verschwindet das Problem im Bundle-Modus – alles in einer Datei.

4.3 Resolve-Operationen reduzieren

Bei jedem import resolved Vite den Pfad – node_modules, Extensionen, Aliase.

Explizite Endungen:

// ❌ Implizite Endung
import Button from './components/Button'

// ✅ Explizite Endung
import Button from './components/Button.tsx'

Weniger Aliase:

// vite.config.ts
export default defineConfig({
  resolve: {
    alias: {
      '@': '/src',
      '@components': '/src/components',
      '@utils': '/src/utils',
      '@hooks': '/src/hooks',
      '@api': '/src/api'
    }
  }
})

Jeder Alias kostet Resolve-Zeit. Ein Haupt-Alias wie @ reicht oft; Rest relative Pfade.

4.4 Native Plugins und Oxc Transform

Vite 6 unterstützt native (Rust-)Plugins – deutlich schneller als JavaScript.

export default defineConfig({
  experimental: {
    enableNativePlugin: true
  }
})

Noch experimentell; die meisten Plugins unterstützen es nicht.

Wichtig: @vitejs/plugin-react v5+ nutzt standardmäßig Oxc Transform statt Babel:

{
  "dependencies": {
    "@vitejs/plugin-react": "^5.0.0"
  }
}

Oxc deckt nicht alle Babel-Features ab. Bei custom Babel-Plugins explizit Babel aktivieren:

import react from '@vitejs/plugin-react'

export default defineConfig({
  plugins: [
    react({
      babel: {
        // Babel erzwingen
        plugins: ['your-babel-plugin']
      }
    })
  ]
})

Fazit

Kurz zusammengefasst:

Environment API verändert die Architektur – normale Projekte merken wenig. Framework-Autoren profitieren, Sie indirekt durch mehr Deploy-Optionen.

Rolldown ist der große Performance-Sprung: 10×+ schnellere Builds, einheitliche Plugins, Dev/Prod-Konsistenz. Linear 46 s → 6 s ist real.

ESM Module Federation entwickelt sich weiter. Community-Lösung produktionsreif, offizielle Lösung noch RC. Micro-Frontends: erst vite-plugin-federation.

Performance: Waterfalls vermeiden, warmup, weniger resolve. Full Bundle Mode löst vieles automatisch.

Migration:

• Produktion: rolldown-vite testen, dann Vite 8 Stable
• Neue Projekte: Vite 8 Beta für Rolldown-Gewinn
• Micro-Frontends: vite-plugin-federation, später Rolldown-native Lösung

Vite wandelt sich von esbuild + Rollup zu einheitlichem Rolldown – von Webpack-kompatibler Federation zu nativem Support. Mit upgraden, wenn es passt – Ihr Projekt wird schneller und stabiler.