L'évolution des applications web a mis en lumière des défis significatifs dans les flux de travail de développement. Avant l'adoption généralisée des modules ES (ESM) par les navigateurs, JavaScript manquait d'un mécanisme natif pour organiser le code en modules. Cette lacune a conduit à l'émergence d'outils de bundling, qui collectent, traitent et assemblent les fichiers sources pour les rendre exécutables dans un navigateur.

Des outils comme webpack et Rollup ont considérablement amélioré l'expérience des développeurs. Cependant, à mesure que les applications gagnent en complexité et en taille, la quantité de code JavaScript à gérer augmente exponentiellement. Il est courant de voir des projets avec des milliers de modules, ce qui entraîne des goulets d'étranglement de performance. Les outils de construction basés sur JavaScript peuvent prendre un temps considérable pour démarrer le serveur de développement. De plus, même avec la mise à jour à chaud des modules (HMR), le temps nécessaire pour que les modifications de code se reflètent dans le navigateur peut être frustrant, impactant négativement la productivité.

Lenteur au Démarrage des Serveurs de Développement

Les bundlers traditionnels comme webpack opèrent en analysant, compilant et packagant l'intégralité du code de l'application. Le résultat est un bundle optimisé et compatible avec différents navigateurs. Ce processus est également appliqué en mode développement, où l'application doit être entièrement construite et packagée avant d'être servie par le serveur de développement. Ce mécanisme se traduit par des temps de démarrage initiaux très lents. Avec la complexité croissante des applications front-end et la taille des projets, le volume de code JavaScript explose, prolongeant les temps de bundling. Les grands projets peuvent voir leurs serveurs de développement prendre des dizaines de secondes, voire plusieurs minutes, pour démarrer.

Mises à Jour Lentes

Une fois le serveur de développement lancé avec un bundler, la reconstruction complète du bundle est inefficace lors des modifications de fichiers. Bien que le HMR existe pour rafraîchir les modulees modifiés, les bundlers doivent souvent recompiler non seulement le fichier modifié, mais aussi ses dépendances. La vitesse du HMR diminue de manière significative à mesure que la taille de l'application augmente, atteignant un plafond de performance avec peu de marge d'optimisation.

L'Approche Révolutionnaire de Vite

Vite tire parti des avancées récentes de l'écosystème front-end pour adresser ces problématiques. Les navigateurs modernes offrent désormais un support natif pour les modules ES, et de plus en plus d'outils front-end sont écrits dans des langages compilés rapides comme Go (ESBuild) et Rust (SWC).

Accélération du Démarrage du Serveur

Vite exploite directement le support natif des navigateurs pour les modules ES (via <script type="module">). Il sert le code transformé directement au navigateur, qui demande individuellement chaque module au serveur de développement, éliminant ainsi la nécessité d'un pré-bundling complet de tous les fichiers. Cela permet un démarrage quasi instantané du projet.

Au lancement, Vite catégorise les modules de l'application en deux groupes pour optimiser le temps de démarrage :

• Dépendances : Les modules des node_modules sont pré-packagés et pré-compilés une seule fois (souvent avec ESBuild pour la vitesse).
• Code source : Les fichiers de l'application sont servis à la demande, en tant que modules ESM natifs.

Mises à Jour Instantanées avec HMR

Dans Vite, le HMR s'exécute sur des modules ES natifs. Lorsqu'un fichier est modifié, Vite invalide avec précision uniquement le module édité et ses limites HMR les plus proches (souvent juste le module lui-même). Il n'y a pas de reconstruction de l'application entière, ce qui garantit que le HMR reste rapide, quelle que soit la taille de l'application. De plus, Vite utilise le cache du navigateur pour accélérer les rechargements de page : les requêtes pour les modules sources bénéficient de la négociation de cache HTTP (304 Not Modified), tandis que les dépendances profitent d'un cache forcé (Cache-Control: max-age=..., immutable), ce qui signifie qu'une fois mises en cache, elles ne sont plus requises.

Qu'est-ce que Vite ?

Vite est un outil de construction front-end de nouvelle génération, s'appuyant sur ESBuild et Rollup. En développement, il utilise les capacités de compilation natives des navigateurs pour les modules ES pour servir les fichiers source à la demande, éliminant l'étape de bundling. Il intègre également un HMR extrêmement efficace dont la vitesse n'est pas affectée par le nombre de modules, améliorant considérablement l'expérience de développement.

Il se compose de deux parties principales :

• Serveur de développement : Exploite les modules ES natifs du navigateur pour servir les fichiers sources et offre un HMR ultra-rapide.
• Build de production : Utilise Rollup pour le bundling en production, avec des optimisations spécifiques fournies par Vite.

Caractéristiques Principales de Vite

• Démarrage à froid rapide : Grâce à l'absence de bundling et à la pré-construction des dépendances avec ESBuild.
• Mises à jour à chaud instantanées : HMR basé sur les modules ES et stratégies de cache intelligentes.
• Chargement véritablement à la demande : Exploitation complète du support natif des modules ES par le navigateur.

Support Navigateur

• Environnement de développement : Nécessite un navigateur supportant l'importation de modules ES natifs.
• Environnement de production : Les navigateurs doivent supporter les modules ES via l'attribut type="module" dans les balises <script>. Le plugin @vitejs/plugin-legacy peut être utilisé pour la compatibilité avec les navigateurs plus anciens.

Le Flux de Travail de Base de Vite

Lorsqu'une balise <script type="module"> est déclarée, comme suit :

<script type="module" src="/src/main.js"></script>

Le navigateur, en analysant la ressource, envoie une requête HTTP au domaine actuel pour obtenir main.js. Si main.js contient des importations, le navigateur envoie ensuite des requêtes HTTP supplémentaires pour le contenu de ces modules. Durant la phase de démarrage du projet, Vite lance un serveur de développement Koa qui intercepte ces requêtes ESM du navigateur. Après avoir traité les modules, le serveur les renvoie au navigateur. Ce mécanisme évite une étape de bundling globale et permet un chargement à la demande des modules.

Interception des Requêtes

Quand le navigateur rencontre une instruction import, il émet une requête HTTP pour le contenu du module. Le serveur de développement de Vite intercepte cette requête, traite le module (par exemple, transpilation, résolution de chemin) et renvoie le résultat approprié.

Réécriture des Chemins de Module

Les navigateurs ne peuvent interpréter que les chemins relatifs (./, ../) ou absolus (/). Cependant, en développement, il est courant d'importer des modules depuis node_modules, ce que le navigateur ne peut pas résoudre directement. Le serveur de développement de Vite, lors de l'interception des requêtes, utilise des bibliothèques comme es-module-lexer et magic-string pour réécrire ces chemins de module, les rendant compréhensibles par le navigateur.

Principes du HMR dans Vite

Le HMR de Vite repose sur une connexion WebSocket établie entre le client (le navigateur) et le serveur de développement. Cette connexion permet au serveur de notifier le client des modifications de fichiers. Quand un fichier est modifié, le serveur de développement envoie des messages au client pour lui indiquer de mettre à jour le code concerné.

Le flux HMR se déroule comme suit :

• Un serveur WebSocket est créé avec un client HMR associé lors du démarrage du service.

Au lancement du projet, Vite injecte le code client HMR dans le HTML.

• Un objet d'écoute (watcher) est créé via la méthode watch de chokidar pour surveiller les changements de fichiers.

import chokidar from 'chokidar';
import path from 'path';

// ... (autres initialisations)

const projectRootPath = '/chemin/vers/votre/projet'; // Chemin racine de l'application
const ignoredPaths = [
  '**/node_modules/**', // Ignorer les dépendances installées
  '**/.git/**',         // Ignorer le répertoire Git
  // ... autres chemins à ignorer
];

const fileWatcher = chokidar.watch(path.resolve(projectRootPath), {
  ignored: ignoredPaths,
  ignoreInitial: true, // Ne pas émettre d'événements pour les fichiers existants au démarrage
  ignorePermissionErrors: true,
  disableGlobbing: false, // Permettre les jokers dans les chemins
  // ... autres options pour chokidar
});

// Écoute des événements de changement de fichier
fileWatcher.on('change', async (changedFilePath) => {
  console.log(`Fichier modifié : ${changedFilePath}`);
  // Logique du serveur pour traiter le changement et notifier le client HMR
});

fileWatcher.on('add', (addedFilePath) => {
  console.log(`Nouveau fichier ajouté : ${addedFilePath}`);
  // Logique pour gérer l'ajout d'un nouveau fichier
});

fileWatcher.on('unlink', (removedFilePath) => {
  console.log(`Fichier supprimé : ${removedFilePath}`);
  // Logique pour gérer la suppression d'un fichier
});

• Lorsqu'une modification de code est détectée, le serveur la traite et pousse les informations de mise à jour vers le client.

Le client HMR dans le navigateur interprète le type de message reçu et exécute l'opération de mise à jour correspondante (par exemple, remplacer un module sans recharger la page).

Optimisations de Vite

Pré-construction des Dépendances

Vite effectue une étape de pré-construction pour les dépendances pour deux raisons principales :

• Compatibilité CommonJS et UMD : Vite fonctionne avec les modules ES natifs. Cependant, de nombreuses dépendances sont publiées en formats CommonJS ou UMD. Vite les convertit en modules ES et les met en cache dans node_modules/.vite.
• Réduction du nombre de requêtes : Certaines dépendances ESM contiennent de nombreux modules internes. Vite les regroupe en un seul module pour améliorer les performances de chargement de page. Par exemple, lodash-es est un ensemble de nombreux modules individuels :

import { debounce } from 'lodash-es'

Vite pré-packagera lodash-es en un seul module pour éviter de multiples requêtes HTTP du navigateur.

Mise en Cache

Cache du Système de Fichiers

Vite met en cache les dépendances pré-construites dans node_modules/.vite. La décision de relancer l'étape de pré-construction dépend de plusieurs facteurs :

• La liste des dépendances dans package.json.
• Les fichiers de verrouillage (lockfiles) du gestionnaire de paquets (package-lock.json, yarn.lock, pnpm-lock.yaml).
• Les modifications éventuelles dans vite.config.js.

La pré-construction n'est relancée que si l'un de ces éléments change. Pour forcer une reconstruction, vous pouvez démarrer le serveur de développement avec l'option --force ou supprimer manuellement le répertoire node_modules/.vite.

Cache du Navigateur

Les requêtes pour les modules sources sont gérées par la négociation de cache HTTP (304 Not Modified). Les dépendances, une fois pré-construites, sont soumises à un cache fort avec Cache-Control: max-age=32536000, immutable. Une fois en cache, ces dépendances ne sont plus demandées, ce qui accélère considérablement les rechargements ultérieurs.

Limitations Actuelles

• Le support pour React n'est pas aussi mature que pour Vue, bien qu'il s'améliore constamment.
• Certains problèmes de compatibilité peuvent subsister avec des navigateurs mobiles plus anciens.
• L'écosystème de plugins de Vite, bien qu'en pleine croissance, n'est pas encore aussi vaste que celui de webpack.