Webpack → Vite : migration du bundler de Storybook

Nous avons migré le bundler de Storybook de Webpack vers Vite. Au cours de ce processus, plusieurs problèmes se sont enchaînés, ce qui nous a finalement conduits à modifier la stack technique existante.

Changement de stack technique

• [Stack technique initiale] Storybook v6.5, builder-webpack5, Node v18, Yarn 1
• [Stack technique finale] Storybook v7, react-vite, Node v18, Pnpm

---

Problèmes rencontrés pendant la migration

1. Problème de compatibilité entre Webpack 4 et OpenSSL 3

• Description du problème

  • Lors de la migration de builder-webpack5 vers builder-vite, un problème de compatibilité de version avec OpenSSL est survenu
  • Les versions de Webpack antérieures à 5.61.0 utilisent une ancienne version d'OpenSSL, et les suivantes utilisent OpenSSL 3
  • Storybook v6 utilise Webpack 4 comme builder par défaut et propose Webpack 5 en option
  • À l'époque, nous avions choisi Webpack 5 et utilisions builder-webpack5 avec Webpack ^5.9.0, ce qui n'avait pas provoqué d'erreur OpenSSL
  • Le builder-vite migré, même s'il effectue le build avec Vite, déclenche ce problème de compatibilité de version OpenSSL car Storybook v6 utilise Webpack 4 comme builder par défaut en interne

• Solution : migration vers Storybook v7

  • Dans Storybook v7, lorsqu'on utilise Vite, Storybook n'utilise pas Webpack 4 en interne, donc l'erreur OpenSSL ne se produit pas

2. Utilisation de dépendances de versions différentes à cause du hoisting de Yarn 1

• Description du problème

  • Le package @isaacs/cliui utilise string-width@5 au format ESM et string-width@4 au format CommonJS (CJS) sous l'alias string-width-cjs
  • Yarn 1 hoiste les packages de dépendances dupliqués vers le dossier racine node_modules, ce qui permet d'accéder à des dépendances qui n'ont pas été installées par le package lui-même
  • Comme string-width@4 et @5 sont des sous-dépendances dupliquées utilisées par plusieurs packages, elles ont été hoistées vers le node_modules racine
  • Parmi les packages string-width, cli-table3, au format CJS, a tenté d'accéder à string-width@4, mais à cause de l'alias, cette même version n'existait pas ; il a donc résolu string-width@5 au format ESM, provoquant un problème de compatibilité de module

• Solution : changer de gestionnaire de paquets pour pnpm, qui n'engendre pas de dépendances fantômes

[tk1583]

Question. Y avait-il une raison de ne pas utiliser esbuild-loader avec webpack ?

Réponse.

Nous avons utilisé Vite afin de tirer parti des fonctionnalités ESM natives.

Si je comprends bien, esbuild-loader est un loader qui permet d’utiliser esbuild dans Webpack. En utilisant esbuild-loader, la vitesse de build devient très rapide, mais il faut malgré tout toujours passer par un processus de bundling.

À l’inverse, avec l’ESM natif, seuls les modules utilisés sont buildés puis envoyés au navigateur, et lorsqu’un module est modifié, seul ce module est rebuildé, ce qui est plus rapide.

Nous avons jugé qu’il était préférable d’utiliser l’ESM natif pour un cas comme Storybook, où seules certaines composants précis sont demandés, et nous avons donc utilisé Vite.