Contexte et motivations

L’auteur décrit un projet initial contenant 47 dépendances de développement, sept fichiers de configuration et un fichier Markdown destiné à l’agent. Cette complexité a entraîné des divergences entre les vérifications locales et le pipeline CI, notamment lors d’un débogage à 2 h du matin. Après trois semaines d’utilisation de Vite+ sur quatre projets, il a adopté une règle simple : inclure la création du projet Vite+ dans le premier prompt de l’IA.

Architecture du toolchain Vite+

Vite+ regroupe plusieurs outils sous le préfixe vp : Vite pour le développement et la construction, Vitest pour les tests, Oxlint et Oxfmt pour le lint et le formatage, tsdown pour la génération de bibliothèques et Vite Task pour la définition de tâches. La configuration centrale se trouve dans vite.config.ts, tandis que les fichiers classiques (package.json, tsconfig.json, etc.) restent présents. Le flux de travail recommandé utilise les commandes suivantes :

vp create
vp check --fix
vp test
vp build
vp migrate
vp run --cache build

Ces commandes peuvent être exécutées globalement (installation via npm i -g vite-plus) ou localement avec npx --package=vite-plus@1.3.0 vp create, ce qui évite de forcer un installateur curl dans chaque dépôt.

Analyse des gains de performance

Dans un monorepo, le temps d’exécution du CI est passé de 4 minutes à 50 secondes après la migration vers Vite+. Le contrôle pré‑commit est passé de 11 secondes à moins de 2 secondes. Ces améliorations proviennent principalement de la réduction du nombre de fichiers de configuration et de la centralisation des vérifications via vp check, qui combine lint, formatage et vérification de type lorsqu'typeAware et typeCheck sont activés par défaut. Le cache intégré aux tâches définies dans vite.config.ts contribue également à la rapidité, bien que le cache ne s’applique pas automatiquement aux scripts package.json sans l’option --cache.

Limites et bonnes pratiques

Le processus de migration n’est pas instantané : vp migrate a duré environ 4 minutes sur un ancien monorepo, convertissant ESLint, Prettier et la configuration tsup. Cette durée dépend du nombre de plugins et de règles personnalisées, qui peuvent nécessiter une intervention manuelle. Une confusion fréquente réside entre les commandes intégrées (vp build) et les scripts du projet (vp run build) ; dans un projet Next.js, l’agent doit explicitement appeler next build plutôt que vp build. Enfin, la gestion des versions Node et du gestionnaire de paquets via vp env doit être explicitée dans les instructions de l’agent, car vp upgrade ne met à jour que le CLI global, pas les dépendances locales.