Webpack Setup zur Bündelung eines Node.js/Express Servers

von Kevin Hall
Webpack Setup zur Bündelung eines Node.js/Express Servers

Wenn man an Webpack denkt, denkt man oft an Frontend-Bundling wie JavaScript, CSS, Bilder usw. Doch Webpack kann auch auf der Serverseite glänzen, insbesondere wenn es darum geht, Node.js Anwendungen effizient zu bündeln. In diesem Beitrag werfen wir einen genaueren Blick auf eine beispielhafte Webpack-Konfiguration für eine Node.js Anwendung mit Express.

Die Konfiguration im Überblick

const path = require('path');
const nodeExternals = require('webpack-node-externals');
const webpack = require('webpack');

module.exports = {
  entry: {
    main: './bin/www'
  },
  output: {
    path: path.join(__dirname, 'prod-build'),
    publicPath: '/',
    filename: 'server.js',
    clean: true
  },
  mode: 'production',
  target: 'node',
  externals: [nodeExternals()],
  module: {
    rules: [
      {
        test: /\.js$/,
        exclude: /node_modules/,
        loader: "babel-loader"
      }
    ]
  },
  plugins: [
    new webpack.IgnorePlugin({
      resourceRegExp: /config\.development\.sample\.json$/
    })
  ]
}

Schritt für Schritt durch die Konfiguration

1. Einstiegspunkt (entry)

entry: {
  main: './bin/www'
}

In Webpack gibt das entry-Feld an, wo dein Anwendungscode startet – also von welchem Punkt aus Webpack beginnt, alle Abhängigkeiten zu analysieren und zu bündeln.

Bei Express-Projekten ist ./bin/www häufig der Einstieg, da hier der HTTP-Server initialisiert wird.

2. Ausgabeort (output)

output: {
  path: path.join(__dirname, 'prod-build'),
  publicPath: '/',
  filename: 'server.js',
  clean: true
}
  • path: Der Zielordner für den gebündelten Code. In diesem Fall wird alles in prod-build gespeichert.
  • filename: Der Name der erzeugten Datei im unserem bsp. hier server.js.
  • clean: true: Stellt sicher, dass der Ausgabeordner vor jedem Build geleert wird. Hilfreich, um veraltete Dateien zu vermeiden.

3. Modus (mode)

mode: 'production'

Webpack kennt drei Modi:

  • development: Für lokale Entwicklung – schnelle Builds, keine Minifizierung.
  • production: Für den Live-Betrieb – Code wird minifiziert, Tree-Shaking aktiviert usw.
  • none: Keine Voreinstellungen, alles manuell konfigurierbar.

Hier wird bewusst der Produktionsmodus verwendet, um die Anwendung möglichst kompakt und performant auszuliefern.

4. Zielumgebung (target)

target: 'node'

Da es sich um eine Node.js Anwendung handelt, sagt man Webpack explizit, dass der Code für eine Node Umgebung bestimmt ist. Dadurch wird z. B. verhindert, dass Node interne Module wie fs oder path gebündelt werden.

5. Externe Abhängigkeiten (externals)

externals: [nodeExternals()]

Hier wird webpack-node-externals genutzt, um alle node_modules aus dem Bundle auszuschließen. Das ist besonders wichtig bei Express-Apps, da viele dieser Module - etwa native Add-ons - zur Laufzeit ohnehin auf dem Server vorhanden sind und nicht in das Bundle aufgenommen werden müssen. Dadurch wird der finaler Build deutlich schlanker, weil du nicht zig MB an bereits vorhandenen Abhängigkeiten reinpackst. Da weniger Code verarbeitet und gebündelt werden muss, baut Webpack das Projekt schneller.

6. Module und Loader

module: {
  rules: [
    {
      test: /\.js$/,
      exclude: /node_modules/,
      loader: "babel-loader"
    }
  ]
}

Diese Regel sorgt dafür, dass alle JS-Dateien (außer in node_modules) mit Babel transpiliert werden. So bleibt der Code auch auf älteren Node.js Versionen kompatibel.

7. Plugins

plugins: [
  new webpack.IgnorePlugin({
    resourceRegExp: /config\.development\.sample\.json$/
  })
]

Mit dem IgnorePlugin kann man bestimmte Dateien bewusst aus dem Bundle ausschließen, hier z. B. eine Entwicklungs-Konfigurationsdatei, die in der Produktionsversion nicht benötigt wird.

Warum Webpack eine überzeugende Wahl ist

Diese webpack.config.js-Datei demonstriert, wie eine Node.js-Anwendung gezielt für den produktiven Einsatz optimiert werden kann. Dabei kommen mehrere bewährte Strategien zum Einsatz, die sich positiv auf Performance und Wartbarkeit der Anwendung auswirken.

Ein zentrales Element ist die sorgfältige Exklusion unnötiger Abhängigkeiten – beispielsweise durch den Ausschluss von node_modules oder durch das gezielte Tree-Shaking nicht benötigter Codeanteile. Dies reduziert die Größe des finalen Bundles erheblich und sorgt dafür, dass nur wirklich benötigte Komponenten in die Produktionsumgebung gelangen.

Durch die Einbindung von Babel wird sichergestellt, dass moderner JavaScript-Code in eine Form übersetzt wird, die mit verschiedenen Node.js-Versionen kompatibel ist. Dadurch wird eine breitere Unterstützung sichergestellt und mögliche Laufzeitfehler durch nicht unterstützte Sprachfeatures werden vermieden.

Ein weiterer wichtiger Aspekt ist die klare Trennung zwischen Entwicklungs- und Produktionskonfiguration. In der Konfigurationsdatei werden gezielt Features deaktiviert, die nur während der Entwicklung benötigt werden – wie z. B. Hot-Reloading oder ausführliche Debugging-Informationen. Gleichzeitig werden produktspezifische Optimierungen wie Minifizierung und Dead-Code-Elimination aktiviert. Das Resultat ist eine deutlich performantere Anwendung, die weniger Angriffsfläche bietet und schneller startet.

Insgesamt schafft diese Webpack-Konfiguration die Grundlage für einen professionellen, stabilen und wartbaren Produktionsbuild einer Node.js-Anwendung.

Zurück

© 2006-2025 exensio GmbH
Einstellungen gespeichert
Datenschutzeinstellungen

Wir nutzen Cookies auf unserer Website. Einige von ihnen sind essenziell, während andere uns helfen, diese Website und Ihre Erfahrung zu verbessern.

Sie können Ihre Einwilligung jederzeit ändern oder widerrufen, indem Sie auf den Link in der Datenschutzerklärung klicken.

Zu den gesetzlichen Rechenschaftspflichten gehört die Einwilligung (Opt-In) zu protokollieren und archivieren. Aus diesem Grund wird Ihre Opt-In Entscheidung in eine LOG-Datei geschrieben. In dieser Datei werden folgende Daten gespeichert:

 

  • IP-Adresse des Besuchers
  • Vom Besucher gewählte Datenschutzeinstellung (Privacy Level)
  • Datum und Zeit des Speicherns
  • Domain
×
Irving Tschepke
Irving Tschepke
Dipl.-Wirtsch.-Ing.
Peter Soth
Peter Soth
Dipl.-Inform. (FH)
Wir antworten in wenigen Stunden.
Oder rufen Sie einfach an:
×
Irving Tschepke
Irving Tschepke
Dipl.-Wirtsch.-Ing.
Peter Soth
Peter Soth
Dipl.-Inform. (FH)
Wir antworten in wenigen Stunden.
Oder rufen Sie einfach an:
You are using an outdated browser. The website may not be displayed correctly. Close