Webpack → Vite: Migration des Storybook-Bundlers

Wir haben den Storybook-Bundler von Webpack auf Vite migriert. Dabei traten mehrere Probleme nacheinander auf, sodass wir letztlich den bestehenden Tech-Stack ändern mussten.

Änderung des Tech-Stacks

• [Bisheriger Tech-Stack] Storybook v6.5, builder-webpack5, Node v18, Yarn 1
• [Finaler Tech-Stack] Storybook v7, react-vite, Node v18, Pnpm

---

Probleme während der Migration

1. Kompatibilitätsproblem zwischen Webpack 4 und OpenSSL 3

• Problembeschreibung

  • Während der Migration von builder-webpack5 zu builder-vite trat ein Kompatibilitätsproblem mit der OpenSSL-Version auf
  • Versionen vor Webpack 5.61.0 verwenden eine ältere OpenSSL-Version, danach wird OpenSSL 3 verwendet
  • Storybook v6 nutzt Webpack 4 als Standard-Builder und bietet Webpack 5 optional an
  • Damals war Webpack 5 ausgewählt, und mit builder-webpack5 auf Basis von Webpack ^5.9.0 trat kein OpenSSL-Fehler auf
  • Der migrierte builder-vite baut zwar mit Vite, aber da Storybook v6 intern standardmäßig Webpack 4 verwendet, trat das Kompatibilitätsproblem mit der OpenSSL-Version auf

• Lösung: Migration auf Storybook v7

  • In Storybook v7 wird bei der Nutzung von Vite intern nicht mehr Webpack 4 verwendet, daher tritt der OpenSSL-Fehler nicht auf

2. Durch Hoisting in Yarn 1 wurden Dependencies mit abweichenden Versionen verwendet

• Problembeschreibung

  • Im Paket @isaacs/cliui werden das ESM-Format string-width@5 und das CommonJS-(CJS)-Format string-width@4 über den Alias string-width-cjs verwendet
  • Da Yarn 1 doppelte Dependency-Pakete in die root node_modules hoistet, kann auf Dependencies zugegriffen werden, die im jeweiligen Paket gar nicht installiert wurden
  • Da string-width@4 und @5 von mehreren Paketen als Sub-Dependencies mehrfach verwendet werden, wurden sie in die root node_modules gehoistet
  • cli-table3 im CJS-Format wollte auf string-width@4 zugreifen, konnte wegen des Alias jedoch nicht dieselbe Version finden und löste stattdessen das ESM-formatige string-width@5 auf, wodurch ein Modul-Kompatibilitätsproblem entstand

• Lösung: Wechsel des Paketmanagers zu pnpm, bei dem keine Phantom-Dependencies entstehen

[tk1583]

Frage. Gibt es einen bestimmten Grund, warum in webpack kein esbuild-loader verwendet wurde?

Antwort.

Wir haben Vite verwendet, um die Native-ESM-Funktionalität zu nutzen.

Soweit ich weiß, ist esbuild-loader ein Loader, mit dem man esbuild in Webpack verwenden kann. Mit esbuild-loader wird der Build zwar sehr viel schneller, aber man muss trotzdem weiterhin den Bundling-Prozess durchlaufen.

Mit Native ESM hingegen werden nur die tatsächlich verwendeten Module gebaut und an den Browser übertragen; wenn sich ein Modul ändert, wird auch nur dieses geänderte Modul gebaut, was schneller ist.

Da bei Storybook häufig nur bestimmte Komponenten angefordert werden, hielten wir den Einsatz von Native ESM für sinnvoll und haben deshalb Vite verwendet.