---
title: "Vite 8.1.0 stable : Bundled Dev Mode (15x au démarrage sur 10k composants React), imports WASM ESM et Chunk Import Map, server.fs.deny étendu avec .npmrc et clés privées"
description: "Vite 8.1.0 stable, publié le 2026-06-23 par la Vite Team (announcing-vite8-1), fait passer Bundled Dev Mode d'un flag expérimental à un point d'entrée documenté --experimental-bundle (15x plus rapide au cold start sur une app React à 10 000 composants, 10x sur les full reloads, et Linear rapporte 3x plus rapide au rendering de cold start, ~40% sur les full reloads), stabilise les imports .wasm directs via WASM ESM Integration et le build.chunkImportMap de la 8.1-beta du 2026-06-15, rapproche Lightning CSS du statut de défaut en ajoutant external-CSS-in-CSS et les dépendances fichiers des plugins, bumpe Rolldown à 1.1.2 (1.1.3 suit le même jour), épingle rolldown avec un tilde range pour que les patchs remontent sans PR Vite, étend server.fs.deny avec .npmrc, .yarnrc.yml et *.{key,p12,pfx,cer,der}, et émet un warning runtime quand envFile: false est utilisé."
date: 2026-06-24
image: "/images/heroes/2026-06-24--vite-8-1-stable-bundled-dev-mode.png"
author: lschvn
tags: ["tooling", "performance"]
tldr:
  - "Vite 8.1.0 stable ([announcing-vite8-1](https://vite.dev/blog/announcing-vite8-1)) est sorti le 2026-06-23 depuis la même [branche 8.1-beta.0](/articles/2026-06-15--vite-8-1-beta-wasm-esm-chunk-importmap) que celle du 2026-06-15. Bundled Dev Mode passe d'un flag à un point d'entrée expérimental documenté : `--experimental-bundle` en CLI ou `experimental.bundledDev: true` dans vite.config.js. 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. Linear a rapporté 3x plus rapide au rendering de cold start, ~40% sur les full reloads, et 10x moins de requêtes réseau."
  - "La release stabilise les deux grosses features de la beta : imports `.wasm` directs via WASM ESM Integration (plus de suffix `?init`) et `build.chunkImportMap`, qui exploite les import maps du navigateur pour garder les hashes de chunk stables quand un seul fichier source change. Elle ajoute aussi `caseSensitive` à `import.meta.glob`, `html.additionalAssetSources` pour les éléments custom, le support des dépendances fichiers et external-CSS-in-CSS pour Lightning CSS (un pas de plus vers le statut de défaut), et renomme les options `server.hmr` en `server.ws` (le seul breaking change de la ligne)."
  - "Autres changements concrets : `server.fs.deny` étend son défaut de `['.env', '.env.*', '*.{crt,pem}', '**/.git/**']` à aussi `.npmrc`, `.yarnrc.yml`, et `*.{key,p12,pfx,cer,der}` (PR #22707) ; rolldown est épinglé avec un tilde range (`~1.1.1`) pour que les 1.1.2 et 1.1.3 remontent sans PR Vite (PR #22693) ; `envFile: false` émet maintenant un warning de deprecation runtime (PR #22555) ; et Rolldown 1.1.3 sort le même jour, corrigeant un crash `defer_drop` sur le main thread du navigateur et un souci de réentrance du close en watch mode."
faq:
  - question: "Quelle est la tête d'affiche de Vite 8.1.0 stable ?"
    answer: "Bundled Dev Mode. La feature n'est plus derrière un flag sans docs : la 8.1 la documente comme `--experimental-bundle` en CLI ou `experimental.bundledDev: true` dans vite.config.js, et explique le compromis dans un design document dédié (vitejs/vite#22746). Le dev server pré-bundle maintenant l'application pour la cible navigateur et sert les chunks préconstruits, au lieu de streamer le module graph unbundled comme Vite le fait depuis la v1. 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 ; Linear a rapporté 3x plus rapide au rendering de cold start, ~40% sur les full reloads, et 10x moins de requêtes réseau en tests à l'échelle production. Les deux autres features stables sont les imports .wasm directs via WASM ESM Integration et `build.chunkImportMap` pour le cache stable des chunks."
  - question: "En quoi Bundled Dev Mode diffère du dev server Vite par défaut ?"
    answer: "Le dev server Vite par défaut est unbundled : il sert chaque module source comme son propre fichier ESM et laisse le navigateur résoudre 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. Les compromis : les plugins tiers qui reposent sur des transforms per-module peuvent avoir besoin de mises à jour, et la feature se concentre sur les plugins côté navigateur et les features core pour l'instant. Elle reste expérimentale parce que la surface de plugins est en cours de définition ; voir vitejs/vite#22746 pour la roadmap."
  - question: "Qu'est-ce qui change entre Vite 8.1-beta.0 et 8.1.0 stable ?"
    answer: "La majeure partie du travail s'est faite dans la beta. La stable ajoute trois features concrètes, des fixes, et un pin structurel. Les features : `server.fs.deny` est étendu avec `.npmrc`, `.yarnrc.yml`, et des extensions de certificat/clé (`key, p12, pfx, cer, der`) pour un dev server secure-by-default moins surprenant (PR #22707). Les fixes : un crash malformed-URI dans le middleware memory-files (PR #22714), un cache `perEnvironmentState` qui perdait les valeurs falsy (PR #22715), un matcher glob hmr qui ignorait l'option caseSensitive (PR #22711), et une erreur de build incrémental `bundled-dev` qui était silencieuse au lieu d'être remontée (PR #22617). Le changement structurel : rolldown est maintenant épinglé avec un tilde range (`~1.1.1`) au lieu d'une version exacte, donc les patch releases comme 1.1.2 (que Vite 8.1 livre) et 1.1.3 (sorti le même jour) remontent dans Vite sans PR par release."
  - question: "Est-ce que les imports .wasm directs et build.chunkImportMap sont prêts pour la production ?"
    answer: "Oui, les deux sont passées de la 8.1 beta à la 8.1.0 stable. Les imports .wasm directs utilisent le draft WASM ESM Integration du WebAssembly community group, donc le path d'import correspond au spec browser-level à venir ; Vite fait encore le parsing binaire et la glue generation en attendant. `build.chunkImportMap` s'implémente au-dessus de la feature chunkImportMap expérimentale de Rolldown et dépend de `import.meta.resolve` dans le navigateur, donc elle ne s'applique pas aux navigateurs plus anciens ; le companion plugin-legacy les couvre avec SystemJS. Les caveats connus : `experimental.renderBuiltUrl` ne marche pas encore avec chunkImportMap, et l'optimisation ne s'applique pas encore au CSS et aux assets, seulement aux chunks JavaScript."
  - question: "Que couvre exactement l'extension de server.fs.deny ?"
    answer: "La liste par défaut de `server.fs.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 la 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 précise que 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. Les projets qui ont des besoins plus stricts peuvent toujours régler `server.fs.deny` explicitement."
  - question: "Est-ce que Vite 8.1 a des breaking changes ?"
    answer: "Un seul : le rename `server.hmr` vers `server.ws` qui a atterri en 8.1-beta.0. Toutes les options WebSocket (host, port, clientPort, path, timeout, overlay) passent de `server.hmr` à `server.ws`, et `server.hmr` devient un toggle booléen. La migration est mécanique : splittez l'ancien bloc `server.hmr: { host, port, ... }` en `server.ws: { host, port, ... }` plus un booléen `server.hmr` si vous en avez besoin. Il y a aussi une deprecation runtime soft : passer `envFile: false` émet maintenant un warning (PR #22555), mais le comportement backward-compatible qui mappe `envFile: false` à `envDir: false` est préservé."
  - question: "Qu'est-ce qu'il y a dans Rolldown 1.1.2 et 1.1.3 ?"
    answer: "Rolldown 1.1.2 (2026-06-18) bumpe oxc_resolver à 11.21.3, ce qui fait que `compilerOptions.paths` résout pour les importers dont l'extension est explicitement listée dans l'`include` d'un tsconfig (par ex. `src/**/*.vue`, `src/**/*.svelte`). Ça débloque le layout par défaut create-vite Vue + TS qui a un root solution-style plus un tsconfig.app.json référencé qui déclare `paths` et `include`. Rolldown 1.1.3 (2026-06-24, même jour que cet article) livre dix fixes : un crash `defer_drop` sur le main thread du navigateur (#9942), un bug camelCase pour les valeurs nested dans la config (#9933), un bug d'affichage `--help` (#9941), un bug preserveModules re-export (#9934), un fix de réentrance close en watch mode (#9904), un fix symlink-as-regular-file pour Git-for-Windows (#9915), l'annulation des full reloads en attente sur erreur de build (#9903), le passage du plugin meta à la fonction `name` des groupes codeSplitting (#9267), servir les assets émis pendant HMR et lazy compile (#9815), et un dry-run release qui ne publish plus les binding packages (#9866)."
  - question: "Quel est le chemin d'upgrade depuis Vite 8.0 ?"
    answer: "Vite 8.1.0 est une release non-breaking pour les projets qui ont déjà migré leur config `server.hmr` vers `server.ws`. Si vous êtes encore sur la ligne 8.0.x, le chemin est `npm install -D vite@8.1.0` (ou `bun add -D vite@8.1.0`) puis une édition de config unique si votre projet règle des options WebSocket sous `server.hmr`. La release ship aussi un changement de défaut security-relevant : `server.fs.deny` bloque maintenant `.npmrc`, `.yarnrc.yml`, et un ensemble plus large de fichiers certificat/clé, donc les projets qui servaient ces fichiers via le dev server (un pattern inhabituel mais possible pour des démos de chargement d'identifiants) devront les ajouter explicitement à `server.fs.allow`."
---

[Vite 8.1.0 stable](https://github.com/vitejs/vite/releases/tag/v8.1.0), publié le 2026-06-23 par github-actions depuis le tag v8.1.0 ([commit 63b1489](https://github.com/vitejs/vite/commit/63b1489), `release: v8.1.0`), est la première release de features sur la [branche stable Vite 8](/articles/2026-04-08--vite-8-stable-seven-patches-in-three-weeks) 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](https://github.com/vitejs/vite/blob/v8.1.0/packages/vite/CHANGELOG.md) 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](/articles/2026-04-08--vite-8-stable-seven-patches-in-three-weeks). L'[announcement post](https://vite.dev/blog/announcing-vite8-1) 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](https://github.com/vitejs/vite/discussions/22746), 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` :

```ts [vite.config.js]
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](https://linear.app) 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](https://github.com/vitejs/vite/discussions/22746) expose le contrat de plugins prévu. Deux follow-ups sont déjà mergés dans la prochaine ligne 8.x : [PR #22587](https://github.com/vitejs/vite/issues/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](https://github.com/vitejs/vite/issues/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](/articles/2026-06-15--vite-8-1-beta-wasm-esm-chunk-importmap) : [PR #21779](https://github.com/vitejs/vite/issues/21779) implémente le draft [WASM ESM Integration](https://github.com/WebAssembly/esm-integration) du WebAssembly community group comme imports `.wasm` directs sans suffix `?init`, et [PR #21580](https://github.com/vitejs/vite/issues/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](https://github.com/vitejs/vite/issues/21748) fait que Vite respecte les dépendances de plugin déclarées par Lightning CSS lui-même, et [PR #18389](https://github.com/vitejs/vite/issues/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](https://github.com/parcel-bundler/lightningcss/issues/479) et [lightningcss#877](https://github.com/parcel-bundler/lightningcss/issues/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](https://github.com/vitejs/vite/discussions/13835).

## Extension de `server.fs.deny`

[PR #22707](https://github.com/vitejs/vite/issues/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](https://github.com/vitejs/vite/issues/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](https://github.com/vitejs/vite/issues/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](https://github.com/vitejs/vite/blob/v8.1.0/packages/vite/CHANGELOG.md) 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](https://github.com/vitejs/vite/issues/22714) gère les URI malformées dans le middleware memory-files.
- [PR #22715](https://github.com/vitejs/vite/issues/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](https://github.com/vitejs/vite/issues/22711) fait que le matcher glob hmr respecte l'option `caseSensitive`.
- [PR #22713](https://github.com/vitejs/vite/issues/22713) omet l'attribut `nonce` sur les import maps quand `cspNonce` n'est pas réglé (un petit fix de correctness HTML).
- [PR #22611](https://github.com/vitejs/vite/issues/22611) skip les exports null-valued dans la résolution glob `expandGlobIds`.
- [PR #22691](https://github.com/vitejs/vite/issues/22691) garde les options de build résolues comme un getter pour que les plugins qui introspectent `config.build` voient les valeurs résolues.
- [PR #22706](https://github.com/vitejs/vite/issues/22706) utilise les queries envPrefix littérales pour Vite Task.
- [PR #22736](https://github.com/vitejs/vite/issues/22736) inline la valeur dev-id dans le sélecteur CSS (une petite optimisation de taille côté client).
- [PR #22724](https://github.com/vitejs/vite/issues/22724) retire l'utilitaire `removeRawQuery` inutilisé.
- [PR #22692](https://github.com/vitejs/vite/issues/22692) renomme les options liées à `chunkImportMap` pour utiliser la propriété `rolldownOptions`.
- [PR #22695](https://github.com/vitejs/vite/issues/22695) bumpe Rolldown à 1.1.2.

## Pourquoi le timing compte

La Vite Team a publié l'[announcing-vite8-1 post](https://github.com/vitejs/vite/blob/v8.1.0/docs/blog/announcing-vite8-1.md) 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](/articles/2026-04-08--vite-8-stable-seven-patches-in-three-weeks), 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](/articles/2026-04-08--vite-8-stable-seven-patches-in-three-weeks) 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.