Webpack → Vite: migração do bundler do Storybook

Migrei o bundler do Storybook de Webpack para Vite. Durante esse processo, vários problemas surgiram em cadeia e, como resultado, foi necessário alterar a stack tecnológica existente.

Mudança na stack tecnológica

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

---

Problemas ocorridos durante a migração

1. Problema de compatibilidade de versão entre Webpack 4 e OpenSSL 3

• Descrição do problema

  • Durante a migração de builder-webpack5 para builder-vite, surgiu um problema de compatibilidade de versão do OpenSSL
  • Versões anteriores à 5.61.0 do Webpack usam uma versão antiga do OpenSSL, e as posteriores usam OpenSSL 3
  • O Storybook v6 usa o Webpack 4 como builder padrão e oferece o Webpack 5 como opção
  • Na época, o Webpack 5 havia sido escolhido, e ao usar o builder-webpack5 com Webpack ^5.9.0, não ocorreu erro de OpenSSL
  • Mesmo que o builder-vite migrado faça o build com Vite, no Storybook v6 o Webpack 4 é usado internamente como builder padrão, então ocorreu o problema de compatibilidade de versão do OpenSSL

• Solução: migrar para o Storybook v7

  • No Storybook v7, ao usar Vite, o Storybook não utiliza internamente o Webpack 4, então o erro de OpenSSL não ocorre

2. Uso de dependências com versões diferentes devido ao hoisting do Yarn 1

• Descrição do problema

  • No pacote @isaacs/cliui, o string-width@5 em formato ESM e o string-width@4 em formato CommonJS (CJS) são usados com o alias string-width-cjs
  • Como o Yarn 1 faz hoisting de pacotes de dependência duplicados para o node_modules raiz, os pacotes podem acessar dependências que não instalaram
  • Como string-width@4 e @5 são subdependências duplicadas usadas por vários pacotes, eles foram movidos por hoisting para o node_modules raiz
  • Entre os pacotes string-width, o cli-table3 em formato CJS tentou acessar o string-width@4, mas por causa do alias a mesma versão não existia; assim, ele resolveu o string-width@5 em formato ESM, causando um problema de compatibilidade de módulos

• Solução: trocar o gerenciador de pacotes para pnpm, que não gera phantom dependencies

[tk1583]

Pergunta. Houve algum motivo para não usar esbuild-loader no webpack?

Resposta.

Usamos o Vite para aproveitar os recursos de Native ESM.

Pelo que sei, esbuild-loader é um loader que permite usar o esbuild no Webpack. Com esbuild-loader, a velocidade de build fica muito rápida, mas ainda é necessário passar pelo processo de bundling.

Por outro lado, com Native ESM, apenas os módulos utilizados são compilados e enviados ao navegador, e quando um módulo é alterado, apenas esse módulo modificado é compilado, então é mais rápido.

Como no Storybook normalmente se solicita apenas componentes específicos, entendemos que usar Native ESM era a melhor opção e por isso adotamos o Vite.