Webpack → Vite: migración del bundler de Storybook

Migramos el bundler de Storybook de Webpack a Vite. En este proceso surgieron varios problemas en cadena y, como resultado, tuvimos que cambiar el stack tecnológico existente.

Cambio de stack tecnológico

• [Stack tecnológico anterior] Storybook v6.5, builder-webpack5, Node v18, Yarn 1
• [Stack tecnológico final] Storybook v7, react-vite, Node v18, Pnpm

---

Problemas que surgieron durante la migración

1. Problema de compatibilidad entre Webpack 4 y OpenSSL 3

• Descripción del problema

  • Durante el proceso de migrar de builder-webpack5 a builder-vite surgió un problema de compatibilidad de versión con OpenSSL
  • Las versiones anteriores a Webpack 5.61.0 usan una versión antigua de OpenSSL, y las posteriores usan OpenSSL 3
  • Storybook v6 usa Webpack 4 como builder predeterminado y ofrece Webpack 5 como opción
  • En ese momento habíamos elegido Webpack 5, y como usábamos builder-webpack5 con Webpack ^5.9.0 no se producía el error de OpenSSL
  • Aunque el builder-vite migrado hace el build con Vite, en Storybook v6 se usa internamente Webpack 4 como builder predeterminado, por lo que surgió el problema de compatibilidad de versión con OpenSSL

• Solución: migrar a Storybook v7

  • En Storybook v7, cuando se usa Vite, Storybook ya no usa internamente Webpack 4, por lo que no ocurre el error de OpenSSL

2. Uso de dependencias con versiones distintas debido al hoisting de Yarn 1

• Descripción del problema

  • En el paquete @isaacs/cliui se usan string-width@5 en formato ESM y string-width@4 en formato CommonJS (CJS) con el alias string-width-cjs
  • Como Yarn 1 hace hoisting de paquetes de dependencias duplicadas al root node_modules, es posible acceder desde un paquete a dependencias que no instaló
  • Como string-width@4 y @5 son subdependencias duplicadas usadas por varios paquetes, fueron elevadas al root node_modules
  • cli-table3, que usa formato CJS dentro del paquete string-width, intentó acceder a string-width@4, pero debido al alias no existía la misma versión, así que resolvió string-width@5 en formato ESM y surgió un problema de compatibilidad de módulos

• Solución: cambiar el package manager a pnpm, donde no se generan phantom dependencies

[tk1583]

Pregunta. ¿Hubo alguna razón para no usar esbuild-loader en webpack?

Respuesta.

Usamos Vite para aprovechar la funcionalidad de Native ESM.

Entiendo que esbuild-loader es un loader que permite usar esbuild en Webpack. Si usas esbuild-loader, la velocidad de build aumenta muchísimo, pero igual hay que pasar por el proceso de bundling.

En cambio, con Native ESM solo se construyen los módulos que se usan y se envían al navegador, y cuando un módulo cambia, solo se vuelve a construir ese módulo, así que es más rápido.

Como en Storybook se suele solicitar solo un componente específico, consideramos que era mejor usar Native ESM, así que elegimos Vite.