Vite 8 a fusionné ses outils de bundling dans Rolldown : qu’est-ce qui a cassé ?

Pendant des années, Vite a secrètement utilisé deux outils de bundling différents — un pendant le développement et un autre pour la mise en production. Rolldown met fin à cette séparation. Les gains de vitesse sont réels, tout comme la liste des problèmes rencontrés.

De nombreuses équipes connaissent les symptômes sans pouvoir identifier la cause : le serveur local affiche un statut vert, tandis que celui en production affiche un statut rouge, et la cause n’est pas une simple faute de frappe. L’environnement d’exécution utilisé pour servir les modules en développement et l’outilchain chargé de les packager pour la production étaient en désaccord concernant un cas particulier. Chez Vite, ce désaccord était structurel : esbuild transformait les fichiers pendant le développement, Rollup les compilait pour la production, et ce mécanisme de liaison était suffisamment fiable pour que les différences restent invisibles — jusqu’à ce qu’elles le deviennent.

Vite 8 élimine cette différence grâce à un seul outil de bundling en Rust : Rolldown. Les tests de performance sont prometteurs, tout comme la liste des applications qui ont cessé de fonctionner lorsque les particularités des deux anciens outils n’avaient plus d’endroit où se cacher. Comprendre les deux approches permet de mettre à jour sans incident inattendu.

Qu’as-t-il changé dans Vite 8

Le choix d’un double moteur semblait rationnel en 2020. Créer un outil de bundling de zéro nécessite des années de travail. esbuild évoluait déjà rapidement ; Rollup disposait déjà d’un écosystème de plugins. Les relier entre eux était une approche pragmatique. Cependant, cela a créé un risque persistant : deux outils interprétant de manière différente les mêmes sources, en particulier pour l’interopérabilité avec CommonJS — ce pont délicat entre les modules require() et l’ESM moderne.

Rolldown représente une solution intégrée à ce problème, regroupant tout dans un seul moteur. Implémenté en Rust, il propose une API de plugins inspirée de Rollup (la plupart des plugins continuent de fonctionner). La version 1.0 stable est prévue pour le 7 mai 2026, avec une API verrouillée conçue pour un usage en production. Vite 8 lui-même est devenu stable le 12 mars 2026 et a fait de Rolldown la valeur par défaut, sans possibilité d’option alternative. Les transformations et minifications qui étaient auparavant gérées par esbuild le sont désormais par Oxc, un autre outil en Rust développé par VoidZero (la même entreprise que Rolldown).

Titre : les builds de production peuvent être générées 10 à 30 fois plus rapidement que Rollup classique. Le mode de développement présente un avantage moins évident. Le « mode bundle complet » empaquette l’application en phase de développement de la même manière que pour la production, au lieu de servir des fichiers ESM bruts un par un. Selon les premiers résultats, le démarrage en mode froid est environ 3 fois plus rapide, les rechargements complets environ 40 % plus rapides, et le nombre de requêtes réseau est réduit d’environ 10 fois. Les gros projets avaient déjà dépassé les limites de l’ESM non empaqueté en phase de développement ; cette solution comble ce manque.

L’avantage structurel est plus simple : un seul moteur pour les deux modes. Les anciens bugs de type « interopérabilité en développement ≠ interopérabilité en production » deviennent impossibles, car il n’y a plus de second outil d’empaquetage susceptible de causer des incohérences.

Qu’est-ce qui a vraiment posé problème

La migration n’a pas été gratuite, et minimiser cet aspect ne sert à personne qui planifie une mise à niveau.

Une interopérabilité CommonJS plus stricte a endommagé les packages. Les exportations CJS ambiguës sont gérées différemment par rapport à l’ancienne combinaison esbuild+Rollup. En l’absence de module.exports.__esModule ainsi que d’une propriété default, Rolldown peut lier une importation à l’ensemble de l’objet module.exports au lieu d’estimer une valeur par défaut comme le faisait l’ancien mode permissif :

// This used to just work under Vite 7 (esbuild + Rollup)
import DOMPurify from 'dompurify';
DOMPurify.sanitize(input);
// Under Rolldown's stricter CJS interop, this can throw:
// TypeError: e is not a function
// because the import resolved to the whole exports object,
// not the function you expected

Propriété dangereuse de cette classe : les outils CI la manquent généralement. jsdom ou les suites de test simulées exécutent rarement le véritable artefact de production. Les erreurs apparaissent lorsque un navigateur charge le résultat compilé. La configuration legacy.inconsistentCjsInterop: true de Vite restaure le comportement permissif ancien pendant que vous recherchez la dépendance problématique.

manualChunks est obsolète au profit de advancedChunks. Ce remplacement n’est pas un simple copier-coller. Certaines équipes ont rencontré l’erreur ReferenceError: Cannot access 'x' before initialization en raison d’effets secondaires liés à l’ordre des chunks après regroupement, et au moins un rapport mentionnait 575 chunks avec le mode de segmentation Rolldown par défaut avant toute mise au point manuelle.

// Old, now-deprecated approach
build: {
  rollupOptions: {
    output: {
      manualChunks: {
        vendor: ['react', 'react-dom'],
      },
    },
  },
}
// Rolldown's replacement - more powerful, but a real migration
build: {
  rolldownOptions: {
    output: {
      advancedChunks: {
        groups: [
          { name: 'vendor', test: /node_modules/, priority: 100 },
        ],
      },
    },
  },
}

Cas documenté : le package @cloudflare/style-provider de Cloudflare (hybride ESM+CJS) a généré l’erreur createRenderer is not a function parce que Rolldown émettait un initialiseur anonyme et inatteignable pour la partie CJS. La correction a fait aliaser ce package vers son entrée CJS dans la configuration Vite — le format purement CJS via l’interopérabilité de Rolldown fonctionnait correctement, mais pas le format hybride.

Hors code d’application : le lien natif en Rust de Rolldown n’a pas pu s’charger dans les WebContainers de StackBlitz, ce qui a rendu inutilisables de nombreux modèles de plateformes d’essai dans le navigateur, jusqu’à ce que les projets utilisent Vite 7 en attendant que le développeur principal résolve le problème.

Liste de vérification pour une migration plus sûre

Les équipes qui ont terminé la transition se concentrent sur des détails précis, plutôt que de simplement « mettre à jour et espérer ».

Bug énigmatiques du type « Vite 7 fonctionne, Vite 8 échoue » : essayez d’abord experimental: { enableNativePlugin: false }. Les plugins natifs en Rust sont désormais par défaut ; les désactiver résout une part surprenante de ces pannes inexplicables.

Chargez le vrai bundle de production dans un véritable navigateur avant de le déployer. jsdom ne détectera pas la classe d’interopérabilité CJS à moins que vous n’exécutiez l’artefact compilé.

Considérez le changement de manualChunks en advancedChunks comme un projet réel nécessitant sa propre série de tests. Les problèmes liés à l’ordre des chunks semblent fonctionnels tant qu’un chemin spécifique n’est pas parcouru.

Réduisez les risques avec rolldown-vite (Vite 7 + prévisualisation Rolldown) sur votre code avant de passer à Vite 8.

Si une dépendance critique n’est pas encore prête pour Rolldown, rester sur Vite 7 pour cette compilation est un choix valable — c’est mieux que d’inventer des solutions temporaires fragiles sous pression de délai.

Qui risque des problèmes

Les dépendances ESM standard et le chunking léger/par défaut : les mises à jour se font généralement sans problème, et la simple compatibilité en vaut déjà la peine. Les manualChunks personnalisés, les paquets hybrides CJS/ESM ou des hébergeurs inhabituels (sandboxes de navigateur, WebContainers) : prévoyez du temps pour la migration et testez l’artefact dans un navigateur. Ces échecs passent les tests CI sans problème et ne se manifestent que chez les utilisateurs réels avec des bundles réels.

Leçon plus large

Lorsque deux systèmes qui se complétaient auparavant sont fusionnés en un seul, les coutures auparavant invisibles apparaissent soudainement. Cela ne signifie pas que l’unification était une erreur. L’égalité entre environnement de développement et environnement de production représente un véritable amélioration structurelle, et les performances restent stables. Cela signifie que « nous avons éliminé les désaccords » et « une série de bugs spécifiques et identifiables apparaîtra pendant la transition » sont en réalité deux aspects d’un même phénomène survenant à des dates différentes. Le scepticisme envers Rolldown est une attitude erronée ; le scepticisme envers un CI en mode vert sans bundle de production chargé dans le navigateur est, quant à lui, justifié.

Que mettre dans la demande de migration

Décrivez cette mise à niveau comme un changement technique avec des critères d’acceptation, et non comme une simple augmentation de dépendances.

Critères suggérés :

1. La compilation pour l’environnement de production s’effectue correctement sous Rolldown, avec les mêmes ressources publiques attendues.

Les parcours d’utilisateur critiques sont testés avec le bundle compilé dans un navigateur réel (et non seulement via des tests unitaires).

Les dépendances CJS hybrides connues sont soit aliasées, mises à jour, soit couvertes par legacy.inconsistentCjsInterop, avec un responsable et une date d’expiration définis.

La stratégie de segmentation des fichiers est examinée en détail : soit on accepte les paramètres par défaut de Rolldown après avoir mesuré le nombre de requêtes, soit on passe de manualChunks à advancedChunks en effectuant un test spécifique.

Les environnements qui ne peuvent pas charger les bindings natifs (par exemple certains hébergeurs WebContainer) disposent d’une version spécifique définie ou d’une solution de contournement documentée.

Si l’un quelconque de ces critères n’est pas respecté, il convient de rester sur Vite 7 ou sur rolldown-vite jusqu’à ce que le critère soit satisfait. Déployer un outil de compilation plus rapide qui perturbe le fonctionnement en production ne constitue pas une amélioration des performances.

Pourquoi les bugs de parité semblent personnels

Les développeurs font confiance au serveur local. Lorsque le serveur local et la version de production cessent de se contredire, les bugs qui se cachaient auparavant dans ces conflits apparaissent en un seul endroit. Cela peut donner l’impression que le mécanisme de propagation a « introduit » des défaillances qui étaient déjà présentes en raison de l’ambiguïté du CJS ou des graphes de chunks. En nommant ce phénomène, on réduit la panique : on ne cherche pas des dégradations aléatoires, mais plutôt on met en évidence les failles que l’époque des deux moteurs masquait.

Gardez les chiffres relatifs à la vitesse. Conservez un design basé sur un seul moteur. Ne confondez simplement pas un ensemble d’unités fonctionnelles avec la preuve que l’artefact compilé fonctionne correctement.