Vite

Appearance

Return to top
On this page

Migration de la v2

Support de Node.js

Vite ne supporte plus Node.js 12 / 13 / 15, qui a atteint son EOL. Node.js 14.18+ / 16+ est maintenant requis.

Changement de base des navigateurs modernes

Le bundle de production suppose le support de JavaScript moderne. Par défaut, Vite cible les navigateurs qui prennent en charge les modules ES natifs, importation dynamique ESM native, et import.meta :

  • Chrome >=87
  • Firefox >=78
  • Safari >=13
  • Edge >=88

Une petite fraction d'utilisateurs devra désormais utiliser @vitejs/plugin-legacy, qui générera automatiquement les chunks hérités et les polyfills de fonctionnalités du langage ES correspondants.

Changements dans les options de configuration

Les options suivantes, qui étaient déjà dépréciées dans la v2, ont été supprimées :

Changements d'architecture et options héritées

Cette section décrit les plus grands changements d'architecture dans Vite v3. Pour permettre aux projets de migrer de la v2 en cas de problème de compatibilité, des options ont été ajoutées pour revenir aux stratégies de Vite v2.

Changements dans le serveur de développement

Le port par défaut du serveur de développement de Vite est maintenant 5173. Vous pouvez utiliser server.port pour le régler sur 3000.

L'hôte par défaut du serveur de développement de Vite est maintenant localhost. Dans Vite v2, Vite écoutait 127.0.0.1 par défaut. Node.js sous v17 résout normalement localhost en 127.0.0.1, donc pour ces versions, l'hôte ne changera pas. Pour Node.js 17+, vous pouvez utiliser server.host pour le définir à 127.0.0.1 pour garder le même hôte que Vite v2.

Notez que Vite v3 imprime maintenant l'hôte correct. Cela signifie que Vite peut afficher 127.0.0.1 comme hôte d'écoute quand localhost est utilisé. Vous pouvez définir dns.setDefaultResultOrder('verbatim') pour éviter cela. Voir server.host pour plus de détails.

Modifications SSR

Vite v3 utilise ESM pour la construction du SSR par défaut. En utilisant ESM, les SSR externalization heuristics ne sont plus nécessaires. Par défaut, toutes les dépendances sont externalisées. Vous pouvez utiliser ssr.noExternal pour contrôler les dépendances à inclure dans le bundle SSR.

Si l'utilisation de ESM pour SSR n'est pas possible dans votre projet, vous pouvez définir legacy.buildSsrCjsExternalHeuristics pour générer un paquet CJS en utilisant la même stratégie d'externalisation que Vite v2.

De plus, build.rollupOptions.output.inlineDynamicImports a maintenant la valeur par défaut false lorsque ssr.target est 'node'. inlineDynamicImports change l'ordre d'exécution et le regroupement en un seul fichier n'est pas nécessaire pour les constructions de noeuds.

Changements généraux

  • Les extensions de fichiers JS en mode SSR et lib utilisent maintenant une extension valide (js, mjs, ou cjs) pour les entrées JS de sortie et les chunks en fonction de leur format et du type de paquet.
  • Terser est maintenant une dépendance optionnelle. Si vous utilisez build.minify : 'terser', vous devez l'installer.
    shell
    npm add -D terser

import.meta.glob

  • Raw import.meta.glob est passé de { assert : { type : 'raw' }} à { as : 'raw' }.

  • Les clés de import.meta.glob sont maintenant relatives au module courant.

    diff
    // fichier : /foo/index.js
const modules = import.meta.glob('../foo/*.js')

// transformé :
const modules = {
- '../foo/bar.js' : () => {}
+ './bar.js' : () => {}
}

  • Lorsqu'on utilise un alias avec import.meta.glob, les clés sont toujours absolues.

  • import.meta.globEager est désormais obsolète. Utilisez plutôt import.meta.glob('*', { eager : true }).

Prise en charge de WebAssembly

La syntaxe import init from 'example.wasm' est abandonnée pour éviter toute collision future avec "ESM integration for Wasm". Vous pouvez utiliser ?init qui est similaire au comportement précédent.

diff
-import init from 'example.wasm'
+import init from 'example.wasm?init'

-init().then((exports) => {
+init().then(({ exports }) => {
  exports.test()
})

Génération automatique de certificats https

Un certificat valide est nécessaire lors de l'utilisation de https. Dans Vite v2, si aucun certificat n'était configuré, un certificat auto-signé était automatiquement créé et mis en cache. Depuis Vite v3, nous recommandons de créer manuellement vos certificats. Si vous souhaitez toujours utiliser la génération automatique de la v2, cette fonctionnalité peut être réactivée en ajoutant @vitejs/plugin-basic-ssl aux plugins du projet.

js
import basicSsl from '@vitejs/plugin-basic-ssl'

export default {
  plugins: [basicSsl()]
}

Expérimental

Utilisation de l'optimisation des deps de esbuild au moment de la compilation

Dans la v3, Vite permet l'utilisation de esbuild pour optimiser les dépendances lors de la construction. Si elle est activée, elle supprime l'une des différences les plus significatives entre dev et prod présente dans la v2. @rollup/plugin-commonjs n'est plus nécessaire dans ce cas puisque esbuild convertit les dépendances CJS uniquement en ESM.

Si vous voulez essayer cette stratégie de construction, vous pouvez utiliser optimizeDeps.disabled : false (la valeur par défaut dans la v3 est disabled : 'build'). @rollup/plugin-commonjs peut être supprimé en passant build.commonjsOptions : { include : [] }

Avancé

Certaines modifications ne concernent que les créateurs de plugins/outils.

Il y a aussi d'autres changements qui n'affectent que quelques utilisateurs.

Migration depuis la v1

Consultez d'abord le Guide de migration depuis la v1 dans la documentation de Vite v2 pour voir les changements nécessaires pour porter votre application vers Vite v2, puis procédez aux changements sur cette page.

Documentation traduite. MIT License. (afc29b4d)

Vite: Copyright © 2019-present Evan You & Vite Contributors