Premiers pas avec Vite+

Vite+ est une chaîne d’outils unifiée pour développeurs, proposée par VoidZero — la société fondée par Evan You, créateur de Vite et Vue — qui regroupe Vite, Vitest, Rolldown, Oxlint, Oxfmt, tsdown et Vite Task derrière une interface en ligne de commande unique nommée vp. Le projet a été annoncé en version alpha le 13 mars 2026 ; le statut alpha a été abandonné avec la v0.1.21 le 13 mai 2026, et la version actuelle au moment de la rédaction est la v0.1.23 (29 mai 2026). Le projet reste en version pré-1.0, il convient donc de le considérer comme un logiciel en phase précoce plutôt qu’une solution éprouvée en production — mais il n’est plus en alpha, et le flux de démarrage principal est suffisamment stable pour être utilisé sur de vrais projets.

Ce guide vous accompagne à travers l’installation de Vite+, la création d’un projet, le lancement du serveur de développement, l’exécution des vérifications et des tests, la génération d’un build de production, et la compréhension de la place de vp dans un flux de travail frontend typique.

Ce qu’est réellement Vite+

Vite+ est une distribution CLI qui regroupe un ensemble sélectionné d’outils frontend derrière un point d’entrée unique. Chaque composant est un projet existant, non une nouvelle invention : Vite 8 en tant que serveur de développement, Rolldown en tant que bundler de production basé sur Rust et compatible avec l’API de Rollup, Vitest en tant que test runner, Oxlint et Oxfmt en tant que linter et formateur construits sur l’infrastructure du compilateur Oxc, tsdown pour le bundling de bibliothèques, et Vite Task pour l’orchestration des tâches et la mise en cache dans les monorepos.

Les gains de performance de ces outils sont structurels, non additifs : Rolldown, Oxlint et Oxfmt partagent Oxc — l’infrastructure de compilateur JavaScript basée sur Rust de VoidZero — comme couche commune d’analyse syntaxique et de transformation. Le gain de vitesse provient du fait que le moteur sous-jacent est rapide par nature, plutôt que chaque outil étant optimisé indépendamment.

Vite+ complète Vite plutôt qu’il ne le remplace. Si vous utilisez déjà Vite, vous pouvez adopter Vite+ de manière progressive ; si ce n’est pas le cas, Vite+ n’est pas le point d’entrée approprié.

Prérequis

Avant l’installation, vérifiez que votre environnement satisfait les exigences d’exécution de Vite 8. Vite 8 requiert Node.js 20.19 ou ultérieur, ou Node.js 22.12 ou ultérieur — Vite+ ne remplace pas Node.js, il gère la version de Node.js utilisée par votre projet via vp env. L’exécution de Vite+ sur une version plus ancienne de Node.js provoquera une erreur avant même le démarrage du serveur de développement.

Vous aurez également besoin d’un shell compatible POSIX sur macOS ou Linux, ou de PowerShell sur Windows.

Installation de Vite+

Vite+ s’installe sous la forme d’un binaire unique appelé vp. Sur macOS ou Linux :

curl -fsSL https://vite.plus | bash

Sur Windows PowerShell :

irm https://vite.plus/ps1 | iex

Redémarrez votre terminal, puis vérifiez l’installation :

vp --version
vp help

Lors de l’installation, Vite+ vous demande s’il doit gérer votre runtime Node.js global. Si vous utilisez déjà nvm, fnm ou asdf, vous pouvez refuser le mode géré et Vite+ s’appuiera sur le Node.js de votre système. Vous pouvez modifier ce comportement ultérieurement avec vp env on ou vp env off.

Création de votre premier projet

vp create génère un nouveau projet à partir d’un template Vite+, en vous invitant de manière interactive à choisir le framework, le gestionnaire de paquets, et TypeScript ou JavaScript :

vp create

L’invite interactive vous permet de sélectionner un template (Vite, Vue, Svelte, Nuxt, Next.js, React Router ou TanStack Start), un gestionnaire de paquets (npm, pnpm, yarn, bun), ainsi que TypeScript ou JavaScript. Pour ignorer l’invite, passez directement un nom de template :

vp create vue my-app
cd my-app
vp install

Le scaffolding génère un unique fichier vite.config.ts qui centralisera la configuration de tous les outils de la chaîne — le linter, le formateur, le test runner et les hooks de fichiers stagés lisent tous depuis ce fichier.

Lancement du serveur de développement avec vp dev

vp dev démarre le serveur de développement Vite 8 avec les paramètres par défaut — aucun flag n’est requis dans le cas courant :

vp dev

vp dev démarre directement le serveur de développement Vite 8. Il n’exécute pas le script dev de votre package.json — c’est un point de confusion fréquent, et c’est l’inverse du comportement de npm run dev. Si votre projet possède un script dev personnalisé (par exemple, un script qui lance un processus backend en parallèle du frontend), invoquez-le explicitement :

vp run dev

La même règle s’applique à vp test et vp build : ce sont des commandes intégrées qui passent par les outils intégrés de Vite+. vp run <script> est la porte de sortie pour les scripts package.json arbitraires, et bénéficie également de la mise en cache basée sur les entrées de Vite Task lorsqu’il est invoqué avec --cache.

Le fichier vite.config.ts unifié

Vite+ centralise la configuration de tous les outils qu’il encapsule — Vite, Vitest, Oxlint, Oxfmt et les hooks de fichiers stagés — dans un unique fichier vite.config.ts à la racine du projet. Au lieu de maintenir des fichiers .eslintrc, .prettierrc et vitest.config.ts séparés, vous exprimez tout via un seul appel defineConfig typé.

Une configuration minimale ressemble à ceci :

import { defineConfig } from 'vite-plus'

export default defineConfig({})

Vous pouvez ensuite ajouter la configuration des outils individuels à mesure que votre projet évolue :

import { defineConfig } from 'vite-plus'

export default defineConfig({
  fmt: {
    singleQuote: true,
    semi: false,
  },
  lint: {
    ignorePatterns: ['dist/**'],
  },
  test: {
    include: ['src/**/*.test.ts'],
  },
})

Vite+ prend également en charge les vérifications de fichiers stagés via un bloc de configuration staged :

import { defineConfig } from 'vite-plus'

export default defineConfig({
  fmt: { singleQuote: true, semi: false },
  lint: { ignorePatterns: ['dist/**'] },
  test: { include: ['src/**/*.test.ts'] },
  staged: {
    '*.{js,ts,tsx,vue,svelte}': 'vp check --fix',
  },
})

Pour activer les vérifications au moment du commit, installez les hooks Git :

vp config

Après cela, Vite+ exécute automatiquement les tâches configurées sur les fichiers stagés lors des commits via vp staged, sans nécessiter de configuration Husky ou lint-staged distincte.

Comme pour le reste de Vite+, le système de configuration est encore en évolution tant que le projet reste en pré-1.0. Si vous adoptez de nouvelles versions, il est conseillé de consulter la documentation officielle et les notes de version pour identifier les changements de configuration avant de mettre à jour.

Exécution des vérifications avec vp check

vp check exécute en une seule passe le formatage, le linting et les vérifications de types sur le projet courant :

vp check

Pour corriger automatiquement ce qui peut l’être sans risque :

vp check --fix

--fix gère la plupart des problèmes de formatage et de nombreuses règles de lint, mais ne peut pas corriger les erreurs de types ni les bugs logiques. Considérez-le comme un correcteur automatique, non comme un substitut à la revue de code. Les vérifications de types sont effectuées par tsgolint (un linter tenant compte des types, construit sur la chaîne d’outils TypeScript Go), et non par une compilation complète tsc --noEmit — rapide pour détecter les erreurs de types courantes, mais pas un substitut à tsc en CI si vous exigez une compilation de types exhaustive. Étant donné qu’Oxlint, Oxfmt et tsgolint partagent une infrastructure alignée sur Oxc, vp check s’exécute sensiblement plus vite qu’une chaîne ESLint + Prettier + tsc --noEmit équivalente sur la même base de code.

Exécution des tests avec vp test

vp test exécute la suite Vitest une seule fois puis se termine — Vite+ inverse le comportement natif par défaut de Vitest qui consiste à rester en mode watch, de sorte que ce comportement est optionnel :

vp test                  # exécution unique (Vite+ ne surveille pas par défaut, contrairement à Vitest)
vp test watch            # activer le mode watch
vp test run --coverage   # exécution unique avec couverture de code

vp test invoque Vitest en utilisant le bloc test dans vite.config.ts. Notez que cela inverse le comportement natif par défaut de Vitest — exécuter vp test seul se termine après un seul passage, alors que vitest autonome resterait en mode watch. Étant donné que Vitest partage déjà le pipeline de transformation de Vite, il n’y a pas de fichier vitest.config.ts séparé à maintenir — le même defineConfig couvre les deux.

Génération d’un build de production avec vp build

vp build compile un bundle de production en utilisant Vite 8 et Rolldown, en émettant le résultat dans dist/ selon les mêmes conventions que vite build :

vp build

vp build compile un bundle de production en utilisant Vite 8 et Rolldown. La sortie est placée dans dist/ en suivant les mêmes conventions que vite build. Étant donné que Rolldown est conçu pour être compatible avec l’API de Rollup, les plugins Rollup existants sont censés continuer à fonctionner — bien que les auteurs de plugins soient encore en train de corriger des cas limites, vérifiez donc tout plugin personnalisé sur une branche avant de vous appuyer sur vp build pour vos releases.

Pour mettre en cache les entrées de build entre les exécutions dans un monorepo :

vp run --cache build

Vite Task calcule une empreinte des entrées déclarées et ignore les paquets dont les entrées sont inchangées lors des exécutions suivantes. C’est la même problématique que Turborepo adresse, mais intégrée directement dans la chaîne d’outils plutôt qu’ajoutée par-dessus.

Un problème courant en production lors du changement de bundler est la régression silencieuse des source maps. Avant de déployer un résultat de vp build, vérifiez que les stack traces dans votre outil de surveillance des erreurs ou de session replay résolvent toujours vers les fichiers sources originaux — c’est l’un des problèmes de migration d’outil de build les plus fréquemment observés par OpenReplay dans les données de sessions réelles.

Référence des commandes vp

Référence à jour pour Vite+ v0.1.23 (29 mai 2026).

Intégration de Vite+ dans GitHub Actions

Pour la CI, VoidZero publie l’action voidzero-dev/setup-vp, qui installe le CLI vp et met optionnellement les dépendances en cache. Un workflow minimal :

name: CI
on: [push, pull_request]
jobs:
  ci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: voidzero-dev/setup-vp@v1
        with:
          node-version: '22'
          cache: true
      - run: vp install
      - run: vp check
      - run: vp test
      - run: vp build

Cela remplace les étapes séparées de lint, formatage, vérification de types et build par quatre invocations vp qui lisent depuis le même fichier vite.config.ts qu’utilisent vos développeurs en local.

Ce qu’il faut savoir avant d’adopter Vite+

Quelques mises en garde honnêtes concernant la version actuelle :

• Oxfmt est toujours en pré-1.0. Comparez son résultat avec votre référence Prettier existante sur une branche avant de basculer vos bases de code en production.
• Les écosystèmes de frameworks ont toujours leurs propres conventions. Bien que Vite+ puisse générer des projets pour des frameworks tels que Nuxt et TanStack Start, la configuration et les flux de travail spécifiques à ces frameworks peuvent continuer à exister en dehors du modèle de configuration unifié de Vite+.
• Pré-1.0 signifie que des changements incompatibles sont possibles. Épinglez la version de vp en CI et consultez le changelog de Vite+ avant toute mise à jour.

Prochaines étapes

Installez Vite+ sur un projet annexe cette semaine, exécutez vp check une fois, et observez ce que ressent votre chaîne d’outils lorsque six outils répondent à une seule commande. Si cette expérience est concluante, essayez vp migrate sur un projet Vite non critique et examinez le diff avant de fusionner — la migration est rapide, mais c’est lors de la revue que vous identifiez les cas limites.

FAQ

Gain Debugging Superpowers

Unleash the power of session replay to reproduce bugs, track slowdowns and uncover frustrations in your app. Get complete visibility into your frontend with OpenReplay — the most advanced open-source session replay tool for developers. Check our GitHub repo and join the thousands of developers in our community.