Claude Code Vite: Build-Tool-Migration und Konfiguration mit KI

Wer einmal mit Vite gearbeitet hat, möchte nicht mehr zurück. Der Entwicklungsserver startet in unter einer Sekunde, Hot Module Replacement (HMR) aktualisiert den Browser in Millisekunden, und der Build ist schneller als jedes Webpack-Setup, das man kannte. Vite ist kein Drop-in-Ersatz — es ist ein Paradigmenwechsel. Und genau deshalb lohnt sich der Einsatz von Claude Code bei Vite: Konfiguration, Migration und Bundle-Analyse werden damit zu lösbaren Aufgaben statt mehrtägigen Rechercheprojekten.

Dieser Artikel zeigt, was Vite technisch ausmacht, wie vite.config.ts aufgebaut ist, welche Plugins sich bewährt haben — und wie Claude Code Vite-Projekte effizienter macht: von der Erstkonfiguration bis zur Webpack-Migration.

1. Was ist Vite — und warum ist es schneller?

Vite (französisch für „schnell“) ist ein Build-Tool der nächsten Generation, entwickelt von Evan You, dem Schöpfer von Vue.js. Der entscheidende Unterschied zu Webpack liegt im Grundprinzip: Vite bündelt im Entwicklungsmodus nicht. Stattdessen nutzt es die nativen ES-Module des Browsers (ESM) — jede Datei wird einzeln angefordert und vom Server direkt als Modul ausgeliefert.

Das bedeutet: Beim Start eines Vite-Dev-Servers müssen nicht erst tausende Dateien zu einem Bundle zusammengebaut werden. Der Server ist bereit, sobald er die Einstiegsdatei kennt. Der Browser lädt dann genau die Module, die er für die aktuelle Route braucht — und nicht das gesamte Bundle. Das ergibt Kaltstartzeiten von unter einer Sekunde, auch bei großen Projekten.

Für den Produktions-Build setzt Vite auf Rollup unter der Haube. Rollup ist bekannt für exzellentes Tree-Shaking und saubere ES-Module-Ausgabe. Vite kombiniert das Beste aus beiden Welten: maximale Entwicklungsgeschwindigkeit durch ESM, optimale Produktions-Bundles durch Rollup.

2. vite.config.ts: Aufbau und wichtige Optionen

Die Konfigurationsdatei von Vite ist bewusst minimal gehalten. Wer von Webpack kommt, ist oft überrascht, wie wenig nötig ist. Eine typische vite.config.ts für ein React-Projekt sieht so aus:

import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
import path from 'path'

export default defineConfig({
  plugins: [react()],
  resolve: {
    alias: {
      '@': path.resolve(__dirname, './src'),
      '@components': path.resolve(__dirname, './src/components'),
    },
  },
  server: {
    port: 3000,
    proxy: {
      '/api': {
        target: 'http://localhost:8080',
        changeOrigin: true,
      },
    },
  },
  build: {
    outDir: 'dist',
    sourcemap: true,
    rollupOptions: {
      output: {
        manualChunks: {
          vendor: ['react', 'react-dom'],
          router: ['react-router-dom'],
        },
      },
    },
  },
})

Die wichtigsten Sektionen im Überblick:

• plugins: Framework-spezifische Plugins, hier @vitejs/plugin-react für JSX-Transformation und Fast Refresh
• resolve.alias: Pfad-Aliase statt relativer Import-Pfade — import Button from '@/components/Button' statt ../../components/Button
• server.proxy: API-Anfragen im Dev-Modus an einen anderen Server weiterleiten — kein CORS-Problem mehr
• build.rollupOptions.manualChunks: Chunk-Strategie für den Produktions-Build

Environment Variables: VITE_* als Konvention

Vite hat eine eigene Konvention für Umgebungsvariablen: nur Variablen mit dem Präfix VITE_ werden in den Client-Code eingebettet. Das ist ein bewusstes Sicherheitsfeature — API-Keys oder Datenbank-Credentials ohne VITE_-Präfix werden nie im Browser landen.

# .env.development
VITE_API_URL=http://localhost:8080
VITE_APP_TITLE=Meine App (Dev)

# .env.production
VITE_API_URL=https://api.meinedomain.de
VITE_APP_TITLE=Meine App

Im Code zugreifen: import.meta.env.VITE_API_URL. TypeScript-Typen für eigene Variablen definiert man in env.d.ts durch Erweiterung des ImportMetaEnv-Interfaces.

3. Plugins: Das Ökosystem

Vites Plugin-System basiert auf dem Rollup-Plugin-Interface, ist aber um Vite-spezifische Hooks erweitert. Die wichtigsten offiziellen Plugins:

• @vitejs/plugin-react: React mit Babel — Fast Refresh, JSX-Transformation, Custom Babel-Plugins
• @vitejs/plugin-react-swc: Schnellere Alternative mit SWC statt Babel — empfehlenswert für große Projekte
• @vitejs/plugin-vue: Vue 3 Single File Components, <script setup>, CSS Modules
• vite-plugin-pwa: Progressive Web App mit Service Worker, Manifest, Offline-Support — komplett konfigurierbar

4. Build-Optimierung: Code Splitting und Chunking

Rollup unter der Haube bedeutet: Vite beherrscht Code Splitting von Haus aus. Dynamische Imports werden automatisch zu separaten Chunks:

// Automatisches Code Splitting durch dynamischen Import
const Dashboard = lazy(() => import('./pages/Dashboard'))
const Settings = lazy(() => import('./pages/Settings'))

Vite erkennt diese Muster und erzeugt separate Chunk-Dateien. Der Browser lädt nur den Code, der für die aktuelle Route benötigt wird. Für große Abhängigkeiten empfiehlt sich eine manuelle Chunking-Strategie über manualChunks in der Rollup-Konfiguration — damit werden Vendor-Bibliotheken (React, Router, UI-Library) sauber von Applikationscode getrennt und können vom Browser gecacht werden.

Ein häufiges Problem in Vite-Projekten: zu viele kleine Chunks, die der Browser einzeln anfordern muss. Die Lösung ist build.chunkSizeWarningLimit als Orientierung und eine durchdachte manualChunks-Strategie.

5. Migration von Webpack zu Vite: Schritt für Schritt

Die Migration von Webpack zu Vite ist in den meisten Fällen möglich, aber nicht trivial. Die häufigsten Stolpersteine:

1. CommonJS vs. ESM: Vite erwartet ESM (import/export), nicht CommonJS (require/module.exports). Abhängigkeiten, die nur CommonJS bieten, muss Vite konvertieren — das passiert automatisch, kann aber langsam sein.
2. Webpack-spezifische Features: require.context, webpack.DefinePlugin, Loader wie raw-loader haben Vite-Äquivalente, aber andere Syntax.
3. Pfad-Auflösung: Webpack erlaubt Extension-Omission und Index-Auflösung standardmäßig für alle Dateitypen; Vite ist strenger.
4. CSS-Handling: CSS Modules, PostCSS, SASS funktionieren, aber die Konfiguration unterscheidet sich.

Ein typischer Migrations-Ablauf:

1. Webpack und seine Plugins/Loader aus package.json entfernen
2. Vite und das passende Framework-Plugin installieren
3. vite.config.ts mit Alias-Mapping der bisherigen Webpack-Aliase erstellen
4. index.html aus dem public/-Ordner in das Root-Verzeichnis verschieben und <script type="module"> einfügen
5. process.env.REACT_APP_* durch import.meta.env.VITE_* ersetzen
6. Dev-Server starten und Fehler systematisch abarbeiten

6. Claude Code Vite: KI-Unterstützung im Alltag

Hier wird die Kombination aus Claude Code und Vite besonders produktiv. Drei konkrete Einsatzszenarien:

vite.config.ts generieren lassen

Statt die Dokumentation nach der richtigen Plugin-Kombination zu durchsuchen, reicht eine Beschreibung:

claude "Erstelle eine vite.config.ts für ein React 18 Projekt mit TypeScript,
path aliases (@/ für src/), einem API-Proxy auf Port 8080, PWA-Support
via vite-plugin-pwa und optimiertem Code Splitting für React und MUI."

Claude Code liest die bestehende package.json, erkennt die installierten Abhängigkeiten und generiert eine Konfiguration, die tatsächlich zu den vorhandenen Versionen passt — nicht eine generische, die vielleicht mit der aktuellen MUI-Version inkompatibel ist.

Webpack-Migration begleiten

Die Migration ist der Bereich, wo Claude Code am meisten Zeit spart. Das Problem dabei: Webpack-Konfigurationen sind oft über viele Dateien verteilt, enthalten Plugins die niemand mehr kennt, und sind historisch gewachsen. Claude Code liest die gesamte bestehende Konfiguration und mappt sie auf Vite-Äquivalente:

claude "Ich möchte dieses Projekt von Webpack 5 zu Vite migrieren.
Lies webpack.config.js, webpack.dev.js und webpack.prod.js und
erstelle eine vollständige vite.config.ts die das gleiche Verhalten
reproduziert. Liste dabei alle Punkte, die manuell nachgearbeitet
werden müssen."

Das Ergebnis ist eine vollständige Migrationsbasis plus eine ehrliche Liste der Stellen, die nicht automatisch übersetzt werden können. Kein Tool-Hoppping mehr zwischen der Webpack-Doku, der Vite-Doku und Stack Overflow.

Bundle analysieren und optimieren

Nach dem Build gibt es oft die Frage: Warum ist das Bundle so groß? rollup-plugin-visualizer erzeugt einen interaktiven Bericht. Claude Code kann diesen analysieren oder direkt auf Basis der Build-Ausgabe Empfehlungen geben:

npm run build 2>&1 | claude "Analysiere diese Build-Ausgabe. Welche Chunks
sind zu groß, und welche manualChunks-Konfiguration würde helfen?"

"Der vendor-Chunk ist mit 487 KB zu groß. date-fns (89 KB) und lodash (71 KB) können als eigene Chunks ausgelagert werden. Zusätzlich: lodash wird komplett importiert, aber nur drei Funktionen genutzt — ersetze durch lodash-es mit gezielten Named Imports für automatisches Tree-Shaking."

Das ist der Unterschied: Claude Code sieht nicht nur die Chunk-Größe, sondern liest den Code, der den Chunk erzeugt, und findet den eigentlichen Grund für die Größe.

• Claude Code Debugging — Build-Fehler und Stack Traces systematisch lösen
• Claude Code für Unternehmen — Team-Workflows und Deployment-Automatisierung