Vite 6 en détail : fédération de modules ESM et optimisation des performances

46 secondes.

C’est le temps que l’équipe Linear attendait à chaque build. Une ligne modifiée, rebuild — 46 secondes de perdues. Fin 2024, passage à Vite 6 et activation de Rolldown : le build tombe à 6 secondes.

J’étais sceptique devant ce chiffre. ×10 ? Ce n’est qu’après un essai en conditions réelles que j’ai constaté que ce n’était pas exagéré.

Vite 6 n’est pas une mise à jour « config légère ». L’Environment API refond le build multi-environnements, Rolldown unifie dev et prod sur le même bundler, et la fédération de modules ESM gagne un soutien officiel en gestation.

Peu perceptible sur un petit projet. En revanche, si vous maintenez une grosse app frontend, un micro-frontend, ou en avez assez du « ça marche en dev, ça casse en prod » — cet article vaut le détour.

Chapitre 1 : Panorama des nouveautés Vite 6

1.1 Environment API : un nouveau paradigme multi-environnements

L’Environment API est le changement d’architecture le plus marquant de Vite 6 — et honnêtement, la plupart des projets n’auront jamais à la toucher.

Avant, Vite exposait surtout client et ssr. Pour Cloudflare Workers, Deno ou d’autres runtimes edge, il fallait bricoler. Les auteurs de frameworks empilaient des hacks pour étendre Vite.

L’Environment API formalise ce bricolage. Exemple de configuration :

// vite.config.ts
export default defineConfig({
  environments: {
    client: {
      // Environnement navigateur
      build: {
        outDir: 'dist/client'
      }
    },
    ssr: {
      // Environnement SSR Node.js
      build: {
        outDir: 'dist/server'
      }
    },
    edge: {
      // Runtime edge (ex. Cloudflare Workers)
      resolve: {
        conditions: ['worker']
      },
      build: {
        outDir: 'dist/edge'
      }
    }
  }
})

Vous vous dites peut-être : je n’en aurai jamais besoin. Probable. C’est surtout pour les auteurs de frameworks — Nuxt, SvelteKit, Astro peuvent mieux cibler divers environnements de déploiement.

Pour une SPA ou MPA classique, rien ne change. Rétrocompatibilité totale, zéro modification de code.

Impact indirect ? Oui. Plus d’environnements côté frameworks = plus de choix : Nuxt sur Cloudflare Workers, Astro sur Deno Deploy — tout cela devient plus réaliste grâce à l’Environment API.

1.2 Support Node.js et impact migration

Vite 6 supporte officiellement Node.js 18, 20, 22+. Node.js 21 est abandonné — version intermédiaire LTS, peu utilisée en production.

Toujours sur Node.js 16 ? Il est temps de migrer. Minimum 18.18.0, requis pour certaines dépendances de Vite.

Points de vigilance à la migration :

• resolve.conditions par défaut : de ['module', 'browser', 'jsnext:main', 'jsnext'] à ['module', 'browser', 'jsnext:main', 'jsnext', 'import']. Si vous l’aviez surchargé, vérifiez.
• Environnements non standards (Deno, Bun) : préciser resolve.conditions explicitement.

En pratique, sur trois projets testés, npm install vite@latest a suffi.

1.3 Autres changements importants

Au-delà de l’Environment API :

API Sass moderne par défaut. Vite utilisait l’ancienne API ; la moderne est maintenant le défaut. En cas d’erreur de compilation :

export default defineConfig({
  css: {
    preprocessorOptions: {
      scss: {
        api: 'legacy' // Revenir à l'ancienne API si besoin
      }
    }
  }
})

Amélioration JSON stringify. Vite détecte les JSON entièrement statiques et prétraite avec JSON.stringify(), ce qui réduit le bundle — utile pour de gros fichiers de config.

Options Worker. worker.format passe de 'iife' à 'es' (Workers en ESM), alignés sur le système de modules du code principal.

Alibaba Cloud - Choix n°1 des développeurs, 15 % de réduction exclusive sur Lighthouse

Obtenir -15 % →Pub

Impact limité au quotidien, sauf Sass : un projet m’a bloqué une demi-journée sur des fonctions custom — l’API modernisée en était la cause.

Chapitre 2 : Intégration Rolldown et bond en performance

2.1 Pourquoi Vite a besoin de Rolldown

Vite 5 : esbuild en dev, Rollup en prod. Deux bundlers différents.

Conséquence ? Dev ultra rapide (esbuild en Go). Prod plus lente (Rollup en JavaScript).

Pire : APIs de plugins incompatibles. Un plugin dev peut échouer en prod — et inversement. Le cauchemar classique : « ça build en local, ça explose en CI ».

Rolldown vise exactement ça.

Qu’est-ce que Rolldown ? Un remplaçant Rollup écrit en Rust, API plugins compatible, 10 à 30× plus rapide que Rollup (benchmarks officiels), vitesse de compilation proche d’esbuild.

Plan Vite : Rolldown remplace Rollup en prod, un seul système de plugins dev/prod, fin des écarts dev vs build.

2.2 Données de performance Rolldown

Les chiffres valent mieux que les discours. L’annonce Vite 8 Beta en liste plusieurs :

Sources : blog officiel Vite 8 Beta.

Gains attendus du Full Bundle Mode :

• Démarrage du serveur de dev ×3 plus rapide
• Rechargement full page −40 %
• Requêtes réseau ÷10

Full Bundle Mode : le dev bundler aussi le projet, au lieu du mode « une requête = un fichier compilé ». Démarrage et refresh plus rapides ; premier démarrage parfois un peu plus long.

Ces chiffres impressionnent. ×10 ? ×30 ? Sur mon monorepo 3000+ fichiers : build Vite 5 ~90 s, Rolldown ~12 s — environ ×7. Pas ×10, mais déjà très net.

2.3 Activer Rolldown (rolldown-vite)

Deux approches :

Option 1 : paquet rolldown-vite

Remplacer vite par rolldown-vite :

// package.json
{
  "dependencies": {
    "rolldown-vite": "latest"
  }
}

Puis dans vite.config.ts :

export default defineConfig({
  build: {
    rolldown: true
  }
})

Idéal pour un essai rapide : Rollup est remplacé automatiquement, compatibilité plugins en général bonne.

Option 2 : attendre Vite 8 stable

Vite 8 Beta intègre Rolldown par défaut :

npm install vite@8

Vite 8 reste en Beta (décembre 2025). Prod : attendre le stable, ou tester rolldown-vite à part.

Chemin de migration recommandé :

1. Tester avec rolldown-vite, valider les plugins
2. Si OK, passer à Vite 8 stable à la sortie
3. Plugin incompatible : désactiver Rolldown temporairement, rester sur Rollup

2.4 advancedChunks remplace manualChunks

Rolldown introduit advancedChunks, plus souple que manualChunks Rollup.

Ancienne façon Rollup :

// Rollup manualChunks (ancienne méthode)
export default defineConfig({
  build: {
    rollupOptions: {
      output: {
        manualChunks: {
          'vendor': ['react', 'react-dom', 'lodash'],
          'utils': ['axios', 'dayjs']
        }
      }
    }
  }
})

Problème : chaque paquet doit être listé manuellement. Oublier une dépendance → elle atterrit dans le chunk principal.

Avec advancedChunks, on travaille par groupes :

// Rolldown advancedChunks (nouvelle méthode)
export default defineConfig({
  build: {
    advancedChunks: {
      groups: [
        {
          name: 'vendor-react',
          test: /react|react-dom/,
          priority: 10
        },
        {
          name: 'vendor-utils',
          test: /lodash|axios|dayjs/,
          priority: 5
        },
        {
          name: 'vendor-shared',
          test: /[\\/]node_modules[\\/]/,
          priority: 1
        }
      ]
    }
  }
})

Priorité haute d’abord ; le dernier groupe attrape le reste. Plus besoin de retoucher la config à chaque nouvelle dépendance — les regex s’en chargent.

Bonus : détection des dépendances dupliquées entre chunks → extraction automatique vers un shared chunk. Très utile en monorepo où plusieurs apps partagent les mêmes libs.

Railway - Plateforme de déploiement moderne, sans opérations complexes, en ligne en quelques minutes

Commencer →Pub

Chapitre 3 : Évolution de la fédération de modules ESM

3.1 Solution communautaire : vite-plugin-federation

Module Federation est la fonction phare de Webpack 5 : des équipes publient des « fédérations » indépendantes et consomment le code des autres. Cool sur le papier — Vite ne le supporte pas nativement.

Réponse communautaire : vite-plugin-federation. 3000+ stars GitHub, la solution la plus mature sous Vite.

Configuration proche de Webpack :

// vite.config.ts - Application Host
import federation from '@originjs/vite-plugin-federation'

export default defineConfig({
  plugins: [
    federation({
      name: 'host-app',
      remotes: {
        remoteApp: 'http://localhost:5001/assets/remoteEntry.js'
      },
      shared: ['react', 'react-dom']
    })
  ]
})

// vite.config.ts - Application Remote
import federation from '@originjs/vite-plugin-federation'

export default defineConfig({
  plugins: [
    federation({
      name: 'remote-app',
      filename: 'remoteEntry.js',
      exposes: {
        './Button': './src/components/Button',
        './Header': './src/components/Header'
      },
      shared: ['react', 'react-dom']
    })
  ]
})

Le Host référence les modules Remote via remotes ; le Remote expose via exposes. shared mutualise les dépendances de base.

Avantages :

• Compatible Module Federation Webpack, interop avec projets Webpack
• Config simple, concepts identiques
• Communauté active, retours d’expérience disponibles

Inconvénients :

• Pas natif Vite — risques de compatibilité plugin
• Build prod via Rollup, logique pas 100 % identique à Webpack
• Debug transversal parfois pénible

3.2 Module Federation natif Rolldown

Bonne nouvelle : Rolldown implémente Module Federation en natif.

Le dépôt rolldown-vite-module-federation-example montre l’usage — encore en RC, pas pour la prod directe.

Atouts de la voie native :

• API alignée Webpack 5 Module Federation
• Même logique de bundling, moins de va-et-vient Vite/Webpack
• Performance Rolldown incluse

La config évolue encore ; forme actuelle :

// Rolldown Module Federation (version RC)
export default defineConfig({
  build: {
    moduleFederation: {
      name: 'host-app',
      remotes: {
        remoteApp: 'remoteApp@http://localhost:5001/remoteEntry.js'
      },
      exposes: {
        './Component': './src/Component.tsx'
      },
      shared: {
        react: { singleton: true },
        reactDom: { singleton: true }
      }
    }
  }
})

Syntaxe proche de vite-plugin-federation, plus proche du standard Webpack. singleton: true garantit une seule version chargée.

3.3 Quelle option choisir

Production : vite-plugin-federation.

Stable, éprouvé, communauté large. Les pièges sont documentés.

Nouveau ou expérimental : Rolldown natif.

Si vous êtes déjà sur Rolldown ou pas encore en prod, vous pouvez tester — prévoyez un plan de retour arrière ; l’API RC peut bouger.

Interop Webpack : les deux conviennent.

vite-plugin-federation est conçu pour ça ; Rolldown promet aussi la compat Webpack 5.

Module Federation n’est pas une baguette magique. Pertinent pour grosses équipes, micro-frontends déployables séparément. Sur un projet simple, vous gérez des frontières fédérées, des versions partagées, du debug inter-projets — souvent un monorepo ou des packages npm suffisent.

Chapitre 4 : Bonnes pratiques d’optimisation

Vite 6 est déjà rapide. Sur un gros codebase — milliers de fichiers, dizaines de deps — quelques leviers restent utiles.

4.1 Préchauffer les fichiers (warmup)

Au démarrage, Vite préchauffe l’entrée et ses deps. Vous pouvez en ajouter :

export default defineConfig({
  server: {
    warmup: {
      clientFiles: [
        './src/main.tsx',
        './src/pages/Home.tsx',
        './src/pages/Dashboard.tsx'
      ]
    }
  }
})

Ces fichiers sont compilés avant l’ouverture du navigateur — première visite sans latence visible.

Cibles utiles :

• Fichier d’entrée (défaut Vite)
• Pages très visitées
• Entrées de grosses libs (lodash-es, etc.)

Ne préchauffez pas tout : trop de fichiers alourdit le démarrage. 5 à 10 fichiers fréquents suffisent.

4.2 Éviter les barrel files

Un barrel file réexporte plein de modules :

// ❌ Barrel file — à éviter
export { Button } from './Button'
export { Input } from './Input'
export { Modal } from './Modal'
export { Table } from './Table'

Import « propre » :

Vultr - Serveur cloud NVMe haute performance, 32 emplacements mondiaux, déploiement Docker en un clic

Voir les tarifs →Pub

import { Button, Input, Modal } from './components'

Mais Vite charge d’abord tout le barrel, puis chaque export — chaîne de requêtes en cascade. Sur un gros projet, plusieurs secondes perdues.

Mieux : imports directs.

// ✅ Import direct
import Button from './components/Button'
import Input from './components/Input'

Chargement parallèle, pas de cascade.

Si vous tenez au barrel pour la lisibilité, le Full Bundle Mode Rolldown atténue le problème — tout est bundlé, plus de chaîne HTTP.

4.3 Réduire les opérations de resolve

Chaque import déclenche un resolve : node_modules, extensions, alias.

Extensions explicites :

// ❌ Extension implicite
import Button from './components/Button'

// ✅ Extension explicite
import Button from './components/Button.tsx'

Moins d’essais .ts, .tsx, .js, .jsx.

Limiter les alias :

// vite.config.ts
export default defineConfig({
  resolve: {
    alias: {
      '@': '/src',
      '@components': '/src/components',
      '@utils': '/src/utils',
      '@hooks': '/src/hooks',
      '@api': '/src/api'
    }
  }
})

Chaque alias coûte du travail. Gardez @ (ou un seul alias principal), le reste en chemins relatifs si possible.

4.4 Plugins natifs et Oxc Transform

Vite 6 supporte les plugins natifs Rust — bien plus rapides que le JavaScript.

export default defineConfig({
  experimental: {
    enableNativePlugin: true
  }
})

Encore expérimental ; peu de plugins compatibles.

À suivre aussi : Oxc Transform. @vitejs/plugin-react v5+ l’utilise par défaut, plus rapide que Babel.

{
  "dependencies": {
    "@vitejs/plugin-react": "^5.0.0"
  }
}

Oxc ne couvre pas toutes les features Babel (plugins custom). Config Babel spécifique :

import react from '@vitejs/plugin-react'

export default defineConfig({
  plugins: [
    react({
      babel: {
        // Forcer Babel
        plugins: ['your-babel-plugin']
      }
    })
  ]
})

Conclusion

L’essentiel :

Environment API : refonte architecturale, impact limité sur les projets courants ; surtout les frameworks gagnent — plus de déploiements possibles pour vous.

Rolldown : le vrai saut perf. Builds ×10 plus rapides, plugins unifiés, cohérence dev/prod. Linear 46 s → 6 s, ce n’est pas du marketing.

Fédération ESM : en mouvement. Communauté mature, officiel en RC. Micro-frontends : vite-plugin-federation maintenant, bascule Rolldown quand stable.

Optimisation : moins de cascades, warmup des fichiers chauds, moins de resolve. Le Full Bundle Mode Rolldown change la donne — le bundler absorbe une partie du travail manuel.

Migration :

• Prod : tester rolldown-vite, puis Vite 8 stable
• Nouveau projet : Vite 8 Beta pour profiter de Rolldown
• Micro-frontend : vite-plugin-federation, puis natif Rolldown

La toolchain Vite évolue vite : esbuild + Rollup → Rolldown unifié ; fédération Webpack-compatible → support natif. Suivre l’actualité et upgrader au bon moment rend vos builds plus rapides et plus fiables.