Comme beaucoup de mes abonnés le savent déjà, nous avons récemment commencé la rénovation de l’interface utilisateur du tableau de bord de l’inspecteur avec un nouveau design et une pile technologique moderne. Dans cet article, j’expliquerai pourquoi nous avons décidé de quitter Webpack et d’adopter Vite comme outil de création d’actifs et de remplacement de module à chaud. Je vais vous montrer comment utiliser HMR (remplacement de module à chaud) sous Windows en travaillant avec une machine virtuelle comme environnement de développement.
Puisque nous utilisons Laravel Homestead comme machine de développement, nous avons eu un peu de mal à comprendre comment utiliser correctement ce nouvel environnement de développement frontal.
Permettez-moi de commencer par un peu de contexte.
Vite contre Webpack
Webpack reconstruit l’intégralité de l’application lorsque vous enregistrez un fichier. C’est pourquoi le changement peut prendre un certain temps pour être reflété dans le navigateur, même avec HMR activé. La boucle de rétroaction lente causée par Webpack crée une mauvaise expérience de développeur pour les développeurs travaillant sur des applications JavaScript de moyenne à grande échelle.
Vite s’appuie à la place sur deux améliorations apportées récemment à l’écosystème JavaScript pour offrir une meilleure expérience de développement : la disponibilité de Modules ES dans le navigateur et outils de regroupement compilés vers natifs comme esbuild.
La disponibilité des modules ES dans le navigateur vous permet d’exécuter une application JavaScript sur le navigateur sans avoir à les regrouper.
L’idée centrale de Vite est de séparer votre application Javascript en deux catégories :
- Toutes les dépendances chargées à partir du node_modules annuaire. Presque tout est répertorié dans le fichier package.json.
- Votre code d’application. Les modules que vous écrivez pour votre application impliquent souvent des fichiers .js, .jsx, .vue ou .scss.
Alors qu’un flux de travail basé sur un bundle comme Webpack devra traiter l’intégralité de vos modules JavaScript avant une seule requête de navigateur, Vite ne traite que vos modules de dépendance avant une seule requête de navigateur.
Vos modules applicatifs seront transformés et servis par Vite lorsqu’ils seront requis par votre application. Littéralement à la volée :
C’est pourquoi Vite est capable de traiter votre build de développement plus rapidement que Webpack.
Une autre caractéristique que j’apprécie est que l’ensemble de l’environnement nécessite très peu de configuration. Vous devez placer un vite.config.js fichier dans le dossier racine de votre projet. Il nécessite très peu d’options pour être prêt à partir, et tout le reste est bien documenté.
Vite Dev Server en action
J’ai remarqué ce comportement différent en ouvrant l’outil de développement Chrome et en naviguant dans mon application :
Comme vous pouvez le constater, Vite sert tous les composants de l’application séparément, et non un seul ensemble, comme c’était le cas avec Webpack.
Cela rend le premier chargement dans le navigateur un peu lent, mais cela rend le remplacement du module à chaud très rapide, voire incroyablement rapide. Parce qu’il ne charge que les modules ES dont il a besoin quand ils sont nécessaires.
Remplacement du module à chaud
Le remplacement de module à chaud (HMR) échange, ajoute ou supprime des modules pendant qu’une application est en cours d’exécution sans rechargement complet. Cela peut considérablement accélérer le développement de plusieurs manières :
- Conserver l’état de l’application qui est perdu lors d’un rechargement complet.
- Gagnez un temps de développement précieux en ne mettant à jour que ce qui a changé.
- Mettez à jour instantanément le navigateur lorsque des modifications sont apportées à CSS/JS dans le code source, ce qui est presque comparable à la modification des styles directement dans les outils de développement du navigateur.
Voici un exemple de HMR en action lors du développement de notre page de connexion :
Comment utiliser Hmr avec VM en tant qu’environnement local
Avec Webpack, nous travaillions en exécutant toutes les commandes directement dans la machine virtuelle Homestead.
Mais l’exécution du serveur de développement Vite (npm run dev) a empêché le HMR de fonctionner.
Le problème n’est pas l’environnement virtualisé en soi. Mais l’environnement virtualisé se trouve au-dessus d’une machine Windows. Cela est dû à la façon dont WSL (Windows Subsystem for Linux) fonctionne actuellement avec le système de fichiers Windows. La solution consiste à utiliser usePolling option dans le fichier de configuration de Vite :
export default defineConfig({
plugins: [vue()],
server: {
watch: {
usePolling: true
}
}
});Considérez que cette option implique une utilisation élevée du processeur.
Vous trouverez une description détaillée du fonctionnement de cette option dans la documentation.
La mise à jour du navigateur après un changement de fichier n’est pas aussi immédiate qu’on le souhaiterait. Mais ça marche.
Comment résoudre le problème HMR
La solution consiste à exécuter le serveur de développement Vite dans votre terminal Windows en dehors de la machine virtuelle Homestead. Je pense que le problème devrait être le même pour d’autres environnements virtualisés comme Docker.
N’oubliez pas que vous devez exécuter le terminal Windows avec une autorisation d’administrateur. Sinon, vous obtiendrez une erreur d’autorisation refusée.
En exécutant la ligne de commande avec des autorisations d’administrateur, le serveur démarrera comme prévu et vous pourrez profiter du HMR pendant le développement de l’interface utilisateur.
Conclusion
Chaque nouvel outil doit être étudié et adapté à notre environnement de développement. J’espère que ce tutoriel vous a aidé à mieux comprendre ce qu’est Vite et comment il améliore l’expérience des développeurs par rapport aux autres technologies utilisées jusqu’à présent.