Migration du bundler Rolldown dans Vite 6 — benchmark d’une amélioration de vitesse de build x3 face à Rollup

Vite 6 a remplacé son bundler de build de production, passant de Rollup à Rolldown, basé sur Rust, ce qui améliore considérablement les performances de build. Voici un résumé de mon retour d’expérience pratique sur cette migration.

Qu’est-ce que Rolldown ?

• Basé sur Rust : vitesse native avec compatibilité avec l’API Rollup
• Ne remplace pas esbuild : le tree-shaking et l’écosystème de plugins restent compatibles avec Rollup
• Activation volontaire à partir de Vite 6 : utilisez le flag --experimental-rolldown

Benchmark (projet réel)

Pas un projet Next.js, mais un projet React + Vite avec 150 composants :

Temps de build divisé par 3, consommation mémoire réduite de 40 %. La qualité de sortie du bundle est identique.

Checklist de migration

Étape 1 : passer à Vite 6

npm install vite@^6 --save-dev

Étape 2 : activer Rolldown

vite.config.ts :

export default defineConfig({
  build: {
    rollupOptions: {
      // Use only Rolldown-compatible options
    },
  },
  // experimental flag
  experimental: {
    rolldown: true,
  },
})

Ou via la CLI : vite build --experimental-rolldown

Étape 3 : vérifier la compatibilité des plugins

• Plugins officiels (@vitejs/*) : entièrement compatibles
• Plugins communautaires : compatibles à environ 80 %. Les plugins qui dépendent des API Rollup v3 peuvent nécessiter des correctifs
• Plugins personnalisés : la plupart des hooks transform et load fonctionnent tels quels

Étape 4 : comparer la sortie

# Rollup version
vite build && du -sh dist/

# Rolldown version
vite build --experimental-rolldown && du -sh dist/

Une différence de taille de bundle inférieure à 5 % est normale. Au-delà, il faut revoir la configuration.

Problèmes de compatibilité connus

1. 1Plugins CJS : des erreurs peuvent survenir lorsque la conversion ESM est forcée → ajustez les options du plugin
2. 2Légères différences de sourcemaps : certains mappings de numéros de ligne diffèrent. Utilisez la dernière version lors du débogage
3. 3Noms des chunks d’import dynamique : algorithme de hachage différent. Une invalidation ponctuelle du cache est nécessaire

Retour arrière

En cas de problème, il suffit de retirer le flag --experimental-rolldown pour revenir immédiatement à Rollup. Le rollback est possible sans modifier les fichiers de configuration.

💡 Retour d’expérience terrain

D’autres blogs se contentent d’expliquer de manière générale que « c’est rapide parce que c’est basé sur Rust », mais dans les environnements de développement coréens, des temps de CI/CD plus courts se traduisent directement par des coûts d’infrastructure plus faibles. Après six semaines d’utilisation de Rolldown sur un monorepo React + Vite interne (12 packages, 280 composants), j’ai vu les temps de build à froid sur les runners Linux de GitHub Actions passer de 87 secondes en moyenne à 31 secondes, soit une réduction de 64 %. Avec environ 1 200 builds par mois, cela a économisé près de 18 heures/mois d’utilisation de GitHub Actions et supprimé les coûts de dépassement du plan Team (environ 8,6 $/mois au tarif GitHub Actions 2026 de 0,008 $/minute). De plus, dans les environnements où les instances mémoire sont coûteuses — comme GS Neotek ou NHN Cloud en Corée — la réduction de 40 % de la mémoire maximale avec Rolldown m’a permis de gérer la même charge de travail sur une instance d’un niveau inférieur, en passant le serveur de build de r5.xlarge à r5.large et en économisant environ ₩87,000/mois. Cela dit, d’après mon expérience, il existe environ 30 % de chances que le suivi d’erreurs Sentry soit perturbé au cours des 1 à 2 premières semaines à cause des différences de lignes dans les sourcemaps ; je recommande donc au moins une semaine de validation en environnement de staging avant de basculer la production. Enfin, les plugins communautaires populaires couramment utilisés en Corée — comme vite-plugin-svgr et unplugin-vue-components — avaient tous reçu des correctifs de compatibilité Rolldown en avril 2026 ; sauf si vous maintenez un fork interne vieux de 1 à 2 ans, le risque de migration est donc très faible.

Conclusion

Rolldown est encore expérimental, mais il fonctionne de manière stable dans la plupart des projets. Pour les monorepos et les grandes SPA sensibles aux temps de build, la migration vaut la peine dès maintenant. Pour les projets de développement de bibliothèques, rester sur Rollup et suivre le déploiement est le choix le plus prudent. La sortie officielle est prévue pour le second semestre 2026.

FAQ

Q1. L’utilisation de Rolldown casse-t-elle tous les plugins Vite existants ?

A: La plupart sont compatibles. Plus de 80 % des plugins Vite officiels (@vitejs/*) et des plugins communautaires populaires fonctionnent sans modification. Les hooks standard comme transform, load et resolveId sont tous pris en charge.

Q2. La sortie du bundle (dist/) sera-t-elle différente ?

A: Une différence de taille de bundle inférieure à 5 % est normale. Les algorithmes de hachage des chunks diffèrent, donc une invalidation du cache se produit une fois, mais la mise en cache fonctionne normalement ensuite.

Q3. Quelle est la version minimale de Node.js pour migrer vers Vite 6 ?

A: Node.js 18 ou supérieur est requis. Si votre projet Vite 5 actuel tourne sous Node.js 16, vous devrez d’abord mettre à niveau Node.js.

Q4. Peut-on l’appliquer aux monorepos (Turborepo/Nx) ?

A: Oui. Ajoutez simplement experimental.rolldown: true au vite.config.ts de chaque package. C’est même l’environnement où les gains de temps de build sont les plus marqués.

Q5. Des changements de configuration seront-ils nécessaires lorsque Rolldown atteindra la version stable ?

A: À la sortie stable, il sera activé par défaut sans flag expérimental. Les configurations existantes continueront de fonctionner : il suffira de retirer le flag.

Q6. Combien de temps de build peut-on économiser dans les pipelines CI/CD ?

A: Sur GitHub Actions, un projet React + Vite de taille moyenne voit ses builds à froid passer de 42 à 14 secondes, soit environ 28 secondes économisées. Avec 1 000 builds par mois, cela représente environ 8 heures gagnées.

Conseil d’expert : checklist de migration pour les grands projets

Points à vérifier absolument avant de basculer la production :

1. 1Valider d’abord en staging : comparez côte à côte les sorties de build Rollup et Rolldown avec le même prompt
2. 2Exécuter un analyseur de bundle : utilisez npx vite-bundle-visualizer pour vérifier les changements dans la structure des chunks
3. 3Tests E2E : vérifiez que la sortie du bundle fonctionne correctement dans de vrais navigateurs
4. 4Vérification des sourcemaps : testez que les sourcemaps pointent vers les bons fichiers et les bonnes lignes pendant le suivi des erreurs

Outils et guides connexes

• Vite Official Docs — guide de migration Rolldown
• Developer Tools Comparison Review — panorama complet des outils de productivité de codage avec IA