Webpack

Was ist Webpack?

Webpack ist ein Module Bundler. Ausgehend von einem oder mehreren Entry Points folgt es jedem Import und erstellt einen Graphen der Module und Assets Ihrer Anwendung. Anschließend transformiert und kombiniert es diese in eine geringe Anzahl von Bundles, die der Browser effizient laden kann.

Webpack wurde 2012 veröffentlicht und wurde zum Rückgrat des modernen Front-End-Builds. Vite ist mittlerweile der Standard für neue Projekte, da es schneller und einfacher ist, aber Webpack treibt immer noch eine enorme Anzahl von Produktionsanwendungen an. Seine Konzepte – der Dependency Graph, Loader, Plugins und Code Splitting – bilden das Vokabular jedes darauf folgenden Bundlers.

Entry und Output

Die zwei erforderlichen Konfigurationspunkte sind der Startpunkt des Graphen und der Zielort für die Bundles.

// webpack.config.js
import path from "node:path";

export default {
  entry: "./src/index.js",
  output: {
    path: path.resolve(import.meta.dirname, "dist"),
    filename: "[name].[contenthash].js",
    clean: true,
  },
};

entry ist das Startmodul. output.filename verwendet einen Content-Hash, damit Browser Bundles dauerhaft cachen und nur geänderte Dateien erneut herunterladen können. clean: true entfernt veraltete Dateien vor jedem Build.

Loader

Standardmäßig versteht Webpack nur JavaScript. Loader transformieren andere Dateitypen in Module, sobald diese in den Graph einfließen.

// loaders.js
export default {
  module: {
    rules: [
      {
        test: /\.tsx?$/,
        exclude: /node_modules/,
        use: "ts-loader",
      },
      {
        test: /\.css$/,
        use: ["style-loader", "css-loader"],
      },
      {
        test: /\.(png|svg|woff2)$/,
        type: "asset",
      },
    ],
  },
};

Eine Regel besitzt ein test, um festzulegen, auf welche Dateien sie zutrifft, und ein use für den zu verwendenden Loader oder die Loader-Kette. Loader werden von rechts nach links ausgeführt, sodass ["style-loader", "css-loader"] zuerst das CSS parst und es anschließend in die Seite injiziert. Webpack 5 bietet zudem Asset Modules, welche den alten file-loader und url-loader für Bilder und Schriftarten ersetzen.

Plugins

Plugins erweitern den Build-Prozess selbst. Während ein Loader eine Datei transformiert, klinkt sich ein Plugin in den Lifecycle der Kompilierung ein.

// plugins.js
import HtmlWebpackPlugin from "html-webpack-plugin";
import { DefinePlugin } from "webpack";

export default {
  plugins: [
    new HtmlWebpackPlugin({ template: "./src/index.html" }),
    new DefinePlugin({
      "process.env.NODE_ENV": JSON.stringify("production"),
    }),
  ],
};

Gängige Plugins generieren die HTML-Datei, definieren Umgebungsvariablen, kopieren statische Assets, analysieren die Bundle-Größe oder bereinigen den Output. Hier liegt der Großteil der Power von Webpack – und auch der Großteil seiner Komplexität.

Resolve und Aliase

Die resolve-Optionen steuern, wie Imports aufgelöst werden.

// resolve.js
export default {
  resolve: {
    extensions: [".ts", ".tsx", ".js"],
    alias: {
      "@": path.resolve(import.meta.dirname, "src"),
    },
  },
};

Mit extensions können Sie Imports ohne Dateiendung durchführen, und alias erstellt Kürzel, damit die Imports nicht mit ../../..-Pfaden überladen werden. Derselbe Alias wird normalerweise in der TypeScript-Konfiguration gespiegelt, damit der Editor mit dem Bundler übereinstimmt.

Code splitting und Tree shaking

Zwei Optimierungen sind entscheidend für die Performance in der Production.

Code splitting unterteilt das Bundle in Chunks, die bei Bedarf geladen werden. Dynamische import() sind hierfür das primäre Werkzeug, während splitChunks gemeinsam genutzte Abhängigkeiten automatisch extrahiert.

// split.js
export default {
  optimization: {
    splitChunks: { chunks: "all" },
  },
};

Tree shaking entfernt ungenutzte Exports, allerdings nur, wenn die Imports statisch analysiert werden können. Das bedeutet, es müssen ES-Module (import/export) anstelle von CommonJS verwendet werden sowie Module, die frei von Side Effects sind. Wenn Pakete in ihrer package.json als sideEffects: false markiert sind, kann Webpack diese aggressiver entfernen.

Der Development-Server

webpack-dev-server stellt den Build in der Entwicklung mit Hot Module Replacement bereit.

// devServer.js
export default {
  devServer: {
    port: 3000,
    hot: true,
    historyApiFallback: true,
    proxy: [{ context: ["/api"], target: "http://localhost:8787" }],
  },
};

historyApiFallback ermöglicht clientseitiges Routing, indem index.html für unbekannte Pfade ausgeliefert wird, und proxy leitet API-Anfragen an dein Backend weiter. Der Dev-Server hält den Build im Arbeitsspeicher, sodass Rebuilds schnell erfolgen.

Wann man Webpack einsetzen sollte

Webpack ist nach wie vor eine starke Wahl, wenn Sie eine bestehende Anwendung warten, auf einen spezifischen Loader oder ein Plugin angewiesen sind oder fortgeschrittene Funktionen wie Module Federation für Micro-Frontends benötigen. Die Konfiguration ist zwar ausführlich, aber sobald man sie versteht, ist sie extrem leistungsfähig und vorhersehbar.

Für neue Projekte ist Vite in der Regel die bessere Standardwahl: schnellerer Start, einfachere Konfiguration und eine moderne Plugin-API. Es lohnt sich dennoch, Webpack zu lernen, da die Konzepte direkt übertragbar sind – die Plugin-Schnittstelle von Vite ist Rollup-kompatibel, und die gleichen Ideen von Graphen, Transforms und Splitting finden überall Anwendung.

Best Practices

• Halten Sie die Konfiguration in separate common-, dev- und prod-Dateien oder -Funktionen aufgeteilt.
• Verwenden Sie Content-Hashes in Dateinamen für langfristiges Caching.
• Bevorzugen Sie ES modules, damit Tree Shaking funktioniert.
• Teilen Sie umfangreiche Features mithilfe von dynamischen Imports auf.
• Markieren Sie Pakete ohne Side-Effects, damit ungenutzter Code entfernt wird.
• Spiegeln Sie resolve.alias in der TypeScript-Konfiguration wider.
• Analysieren Sie das Bundle mit einem Visualisierer, wenn es unerwartet anwächst.

Häufige Fehler

• Alles in einem einzigen Bundle ausliefern und niemals Code Splitting einsetzen.
• CommonJS verwenden und sich wundern, warum Tree Shaking nicht funktioniert.
• Einen Loader in der falschen Reihenfolge platzieren und dadurch verwirrende Fehlermeldungen erhalten.
• Konfigurationen über verschiedene Umgebungen hinweg duplizieren, anstatt sie modular zu komponieren.
• Aliasing in Webpack, aber nicht in TypeScript konfigurieren, sodass der Editor Fehlermeldungen ausgibt.
• Ein Plugin hinzufügen, das eine bereits integrierte Funktion von Webpack 5 dupliziert.

Wie geht es weiter?

Webpack ist das historische Fundament moderner Build-Tooling-Landschaften und nach wie vor eine zuverlässige Wahl für bestehende Anwendungen. Vergleiche es bei neuen Projekten mit Vite, verschaffe dir einen Überblick über die npm-Pakete, die Loader und Plugins bereitstellen, und schau dir an, wie dieselben Konzepte in Turborepo für Monorepo-Builds implementiert sind. Lies anschließend die Webpack-Konfiguration deines Projekts und verfolge den Weg einer einzelnen Datei vom Entry bis zum Output.