Vite 8 et Rolldown : ce que la mise à jour d'un outil de build dit de votre logiciel
Vite, l'outil qui construit une grande partie des applications web modernes, a changé de moteur le 12 mars. Pourquoi un dirigeant devrait s'y intéresser.
Le 12 mars, l'équipe de Vite a publié la version 8 de son outil. Vite est ce qui transforme le code d'une application web en fichiers prêts à être servis aux utilisateurs, et il est utilisé par une grande partie des applications modernes, avec 65 millions de téléchargements par semaine selon ses auteurs. Cette version remplace entièrement son moteur. Pour un dirigeant, ce n'est pas un sujet technique de plus : c'est un bon exemple de ces mises à jour qui, faites à temps, ne coûtent presque rien, et repoussées, finissent en chantier.
Ce qui a changé
Jusqu'ici, Vite utilisait deux outils différents : esbuild pendant le développement, Rollup pour la version de production. Deux moteurs, deux comportements, et parfois des écarts entre ce que voit le développeur et ce que reçoit l'utilisateur. Vite 8 les remplace par un seul, Rolldown, écrit en Rust, un langage réputé pour sa rapidité.
- La vitesse : l'équipe annonce des constructions 10 à 30 fois plus rapides qu'avec Rollup. Des entreprises citent des gains réels, comme Linear, dont la construction de production est passée de 46 à 6 secondes.
- La compatibilité : une couche de conversion reprend automatiquement les anciens réglages, si bien que beaucoup de projets n'ont rien à modifier. Les extensions existantes restent compatibles.
- Les prérequis : les mêmes versions de Node.js que Vite 7.
- Quelques nouveautés pour les développeurs : des outils de diagnostic intégrés, la remontée des erreurs du navigateur dans le terminal.
The Register note une réserve : au moment de la sortie, Rolldown lui-même était encore en version candidate, et sa fonction de compression du code en version alpha. Les chiffres de vitesse viennent de l'équipe de Vite ; des comparatifs indépendants donnent des classements différents selon les outils.
Pourquoi ça vous concerne
Des minutes gagnées à chaque version
Chaque modification d'une application passe par une construction, souvent plusieurs fois par jour, sur les postes des développeurs et sur les serveurs de test. Quand une construction passe de plusieurs minutes à quelques secondes, ce sont des corrections livrées plus vite et des serveurs de test moins sollicités. Ce n'est pas spectaculaire, mais c'est du temps de développement que vous payez.
La dette des dépendances
Une application web moderne repose sur des centaines de briques open source : Vite, un cadre comme React ou Vue, des bibliothèques pour les dates, les formulaires, les graphiques. Chacune évolue. Les suivre au fil de l'eau coûte quelques heures par trimestre. Les ignorer pendant trois ans, c'est se retrouver bloqué : une faille de sécurité corrigée seulement dans une version récente, une bibliothèque abandonnée, une mise à jour qui en entraîne dix autres. Le jour où il faut agir vite, la marche est trop haute.
Une migration se prépare
L'équipe de Vite recommande elle-même, pour les gros projets, de passer d'abord par une étape intermédiaire, une version de Vite 7 qui utilise déjà Rolldown, avant de passer à Vite 8. C'est la bonne façon de faire en général : une étape à la fois, testée, réversible.
Ce que vous voyez, vous, en tant qu'utilisateur
Rien, dans le meilleur des cas, et c'est bien le but. Un changement de moteur de construction ne modifie ni les écrans ni les fonctions de votre application. Ce que vous pouvez remarquer, à terme, ce sont des corrections livrées plus vite, des fichiers parfois plus légers donc des pages qui s'affichent plus rapidement, et une équipe qui passe moins de temps à attendre ses outils. Si une mise à jour de ce type provoque un changement visible, c'est qu'elle a été mal testée.
C'est aussi pour cela qu'une politique de mise à jour se juge sur la durée. Une application qui suit ses dépendances version après version encaisse sans douleur un changement de moteur comme celui-ci. Une application restée figée sur des briques anciennes devra franchir plusieurs marches d'un coup, avec le risque et le coût que cela suppose.
Ce qu'on conseille
- Ne pas migrer dans la semaine une application en production qui fonctionne. Attendre quelques versions correctives et la stabilisation de Rolldown est raisonnable.
- Demander à votre prestataire sa politique de mise à jour : à quel rythme les dépendances sont-elles revues ? Les mises à jour de sécurité sont-elles appliquées en priorité ?
- Exiger des tests automatisés : ce sont eux qui permettent de mettre à jour sans crainte. Sans tests, chaque mise à jour est un pari.
- Prévoir la maintenance dans le budget dès la conception, plutôt que de la découvrir au moment d'une panne.
C'est ce que comprend notre maintenance des plateformes SaaS et logiciels métier que nous livrons : suivi des dépendances, correctifs de sécurité, réponse sous 24 heures ouvrées. Le code source et la documentation vous sont remis, si bien que vous n'êtes pas prisonnier d'un prestataire. Nos prix sont affichés sur la page Tarifs. Et puisque chaque brique ajoutée est aussi une porte d'entrée possible, relisez notre article sur la mise à jour piratée de Notepad++.