Vite 8.1.0 stable, publié le 2026-06-23 par github-actions depuis le tag v8.1.0 (commit 63b1489, release: v8.1.0), est la première release de features sur la branche stable Vite 8 depuis la 8.1-beta du 2026-06-15. La release ship la même code line que celle de la beta, plus un nouveau point d'entrée expérimental documenté (Bundled Dev Mode), trois semaines de patchs de bug-fix (le CHANGELOG de la beta liste 22 commits entre v8.1.0-beta.0 et v8.1.0), une liste par défaut server.fs.deny resserrée, une dépendance Rolldown épinglée avec un tilde qui permet au bundler de ship des patch releases sans PR Vite, et un warning de deprecation runtime pour envFile: false. Le même jour, Rolldown 1.1.3 sort avec dix fixes de suivi dont un crash sur le main thread du navigateur et un fix de réentrance close en watch mode.
La release arrive huit jours après la beta, plus rapide que la cadence Vite 7 → Vite 8. L'announcement post de la Vite Team note que Vite est maintenant à 41,6 millions de téléchargements hebdomadaires sur npm, « presque au total des téléchargements de Vite 7 ». Bundled Dev Mode est la feature qui justifie à elle seule le bump de minor line : 15x d'amélioration au cold start sur une app React à 10 000 composants, et Linear en conditions réelles à 3x plus rapide au cold start et 10x moins de requêtes réseau.
Bundled Dev Mode, la tête d'affiche
Le plus gros ajout de la 8.1.0 stable est Bundled Dev Mode, qui n'est plus un flag sans docs. Il a maintenant un point d'entrée CLI dédié, --experimental-bundle, et une option de config documentée, experimental.bundledDev: true :
import { defineConfig } from 'vite'
export default defineConfig({
experimental: {
bundledDev: true,
},
})
Le dev server Vite par défaut est unbundled : chaque module source est servi comme son propre fichier ESM, et le navigateur résout l'import graph. C'est ce qui a rendu Vite rapide à petite échelle, mais au fur et à mesure que les apps dépassaient quelques milliers de modules, l'overhead par-module dominait le cold start et les full reload. Bundled Dev Mode garde la même ergonomie de dev server (HMR, pipeline de plugins, env vars) mais pré-bundle l'application avec Rolldown et sert les chunks préconstruits. La Vite Team a mesuré 15x plus rapide au cold start sur une app React à 10 000 composants, 10x sur les full reloads, et le HMR reste instantané quelle que soit la taille de l'app ; l'équipe Linear a rapporté 3x plus rapide au rendering de cold start, ~40% sur les full reloads, et 10x moins de requêtes réseau sur leur app.
La feature reste expérimentale parce que la surface de plugins est en cours de définition. Les release notes soulignent que « si vous utilisez un plugin tiers, il peut ne pas marcher avec ce mode » et que le focus est sur les features core côté navigateur pour l'instant ; le design document expose le contrat de plugins prévu. Deux follow-ups sont déjà mergés dans la prochaine ligne 8.x : PR #22587 a replié bundledDev dans DevEnvironment au lieu d'en faire une sous-classe séparée (livré en 8.1-beta.0), et PR #22617 s'assure que les erreurs de build incrémental sont remontées plutôt que silencieuses en mode bundled-dev.
WASM ESM Integration et Chunk Import Map passent en stable
Les deux grosses features de la beta passent en stable sans changement depuis la branche 8.1-beta.0 : PR #21779 implémente le draft WASM ESM Integration du WebAssembly community group comme imports .wasm directs sans suffix ?init, et PR #21580 ajoute build.chunkImportMap, une option de build opt-in qui exploite les import maps du navigateur pour garder les hashes de chunk stables quand un seul fichier source change.
La feature WASM remplace le pattern import init from './add.wasm?init'; const instance = await init(); par import { add } from './add.wasm'. Vite parse le binaire, extrait les imports et exports, et émet du glue code qui retourne une instance WebAssembly.Module proprement typée. Les suffixes de query legacy ?init, ?url, et ?raw marchent toujours, donc les projets existants n'ont pas besoin de migrer en lockstep. La feature est indépendante du support navigateur aujourd'hui, parce que Vite fait encore le parsing et la glue generation ; le spec browser-level standardise juste la cible long-terme.
La feature chunk import map compte à une autre échelle : c'est une vraie amélioration de stabilité de cache pour les builds de production, pas un confort de dev server. Dans un build Rolldown par défaut, chaque filename de chunk contient un content hash, et les instructions d'import pointent directement sur l'URL hashée. Quand un seul fichier source change, chaque chunk qui l'importe (directement ou transitivement) obtient un nouveau hash, ce qui cascade à travers l'import graph et invalide plus de chunks que strictement nécessaire. Les import maps découplent l'instruction d'import de l'URL du chunk : l'instruction dit import { x } from '/chunks/x.js', l'import map dit /chunks/x.js résout en /chunks/x-abc123.js, et quand le contenu du chunk est inchangé l'URL hashée reste la même et le navigateur la réutilise. L'implémentation dépend de import.meta.resolve dans le navigateur, donc chunkImportMap ne marche que sur les navigateurs qui le supportent ; le companion plugin-legacy couvre les navigateurs plus anciens avec SystemJS.
Lightning CSS, un pas de plus vers le statut de défaut
PR #21748 fait que Vite respecte les dépendances de plugin déclarées par Lightning CSS lui-même, et PR #18389 ajoute le support des fichiers CSS externes importés dans des fichiers CSS. Les deux pièces étaient déjà livrées comme issues Lightning CSS (lightningcss#479 et lightningcss#877) et sont maintenant wirées dans Vite. Les release notes disent que l'équipe « pense à changer le préprocesseur CSS par défaut vers Lightning CSS dans la prochaine release majeure ». Pour l'essayer maintenant, réglez css.transformer: 'lightningcss' dans vite.config.js et partagez votre feedback dans vitejs/vite#13835.
Extension de server.fs.deny
PR #22707 (sapphi.red, feat: extend server.fs.deny list with common files) resserre le dev server secure-by-default. La liste deny passe de ['.env', '.env.*', '*.{crt,pem}', '**/.git/**'] (Vite 8.0.x) à ['.env', '.env.*', '*.{crt,pem,key,p12,pfx,cer,der}', '.npmrc', '.yarnrc.yml', '**/.git/**'] (Vite 8.1.0). Les nouvelles entrées couvrent le matériel clé/certificat dans les fichiers .key, .p12, .pfx, .cer, et .der (la même famille que la couverture existante .crt et .pem) plus les fichiers d'identifiants des package managers .npmrc et .yarnrc.yml.
La description de la PR est explicite : ce n'est pas présenté comme un fix de vulnérabilité, on ne peut pas couvrir tous les fichiers sensibles possibles, mais on ajoute les communs au fil de l'eau, et la liste est documentée comme la surface d'override. En pratique ce genre de changement prévient les fuites d'identifiants accidentelles quand un développeur sert le répertoire racine d'un projet sans configuration server.fs.allow custom, ce qui est le défaut pour les nouveaux projets. Le comportement est le même en dev et en mode SSR.
Rolldown épinglé en tilde
PR #22693 (use ~ for Rolldown) est petit mais à signaler pour les utilisateurs de l'écosystème. Le package.json de Vite épinglait précédemment rolldown comme "rolldown": "1.1.1" (version exacte) ; la 8.1.0 l'épingle comme "rolldown": "~1.1.1" (tilde range, accepte tout 1.1.x). La motivation est opérationnelle : Rolldown ship des patch releases sur une cadence plus rapide que Vite, et Vite devait bumper rolldown manuellement à chaque patch release. Avec le tilde range, 1.1.2 (2026-06-18) et 1.1.3 (2026-06-24) remontent dans les installs des utilisateurs Vite via le lockfile sans PR Vite à chaque coup.
Le risque est la dérive de version en tilde range : un patch Rolldown qui atterrit en 1.1.x et change du comportement peut atterrir dans l'install d'un utilisateur Vite sans release Vite explicite. La mitigation est que le semver patch est censé être backwards-compatible, et la cadence de release de la Vite Team est assez rapide pour ship un patch Vite en un jour ou deux si un mauvais patch rolldown passe. La release 1.1.3 le même jour que cet article illustre le nouveau rythme : un fix de bug Rolldown peut être dans les installs des utilisateurs Vite en quelques heures après le merge.
Warning de deprecation envFile: false
PR #22555 ajoute un warning de deprecation runtime quand envFile: false est utilisé. Le comportement ne change pas ; le mapping backward-compatible existant de envFile: false vers envDir: false est préservé. La motivation est que envFile était déjà marqué deprecated dans la définition de type, mais le chemin runtime restait silencieux, ce qui rendait la migration plus dure pour les utilisateurs de l'API programmatique et laissait un comportement inconsistent avec les autres options Vite deprecated qui warn quand utilisées. Le fix est un warning d'une ligne plus les tests de config qui vont avec ; les utilisateurs déjà sur envDir: false ne reçoivent pas de warning.
Autres changements entre beta et stable
Le diff CHANGELOG de 22 commits entre v8.1.0-beta.0 et v8.1.0 est en grande partie des bug fixes plus le bump Rolldown 1.1.2 :
- PR #22714 gère les URI malformées dans le middleware memory-files.
- PR #22715 cache les valeurs falsy dans
perEnvironmentState, un petit fix de correctness pour les environments qui ré-évaluaient du travail coûteux à chaque requête. - PR #22711 fait que le matcher glob hmr respecte l'option
caseSensitive. - PR #22713 omet l'attribut
noncesur les import maps quandcspNoncen'est pas réglé (un petit fix de correctness HTML). - PR #22611 skip les exports null-valued dans la résolution glob
expandGlobIds. - PR #22691 garde les options de build résolues comme un getter pour que les plugins qui introspectent
config.buildvoient les valeurs résolues. - PR #22706 utilise les queries envPrefix littérales pour Vite Task.
- PR #22736 inline la valeur dev-id dans le sélecteur CSS (une petite optimisation de taille côté client).
- PR #22724 retire l'utilitaire
removeRawQueryinutilisé. - PR #22692 renomme les options liées à
chunkImportMappour utiliser la propriétérolldownOptions. - PR #22695 bumpe Rolldown à 1.1.2.
Pourquoi le timing compte
La Vite Team a publié l'announcing-vite8-1 post le même jour que la release, ce qui est un turnaround plus rapide que d'habitude de « beta » à « stable + announcement » (huit jours pour la 8.1 contre environ trois semaines pour la ligne 8.0). Le stat 41,6M de téléchargements hebdomadaires rappelle que Vite est maintenant dans la même base d'install que React, et les métriques de Bundled Dev Mode sont le genre de chiffres en gros titre qui justifient un bump de minor line à eux seuls.
Pour les utilisateurs sur la ligne stable Vite 8, l'upgrade est npm install -D vite@8.1.0 plus une édition de config unique si votre projet règle des options WebSocket sous server.hmr. Pour les utilisateurs encore sur Vite 7 ou plus ancien, les release notes Vite 8 stable couvrent la migration Rolldown et les changements plus larges de la surface de plugins. La ligne 8.1 est la cible stable recommandée pour les nouveaux projets aujourd'hui, avec 8.2 et 9.0 déjà ouverts comme milestones sur le repo Vite.
