Bâtir pour produire #

Quand il est temps de déployer votre application pour la production, exécutez simplement la commande vite build. Par défaut, elle utilise <root>/index.html comme point d'entrée de la construction, et produit un paquet d'application qui est approprié pour être servi sur un service d'hébergement statique. Consultez la page Deploying a Static Site pour des guides sur les services les plus populaires.

Compatibilité avec les navigateurs #

Le paquet de production suppose le support du JavaScript moderne. Par défaut, Vite cible les navigateurs qui prennent en charge les modules native ES Modules, native ESM dynamic import, et import.meta :

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

Vous pouvez spécifier des cibles personnalisées via l'option de configuration build.target, où la cible la plus basse est es2015.

Notez que par défaut, Vite ne gère que les transformations syntaxiques et ne couvre pas les polyfills par défaut. Vous pouvez consulter Polyfill.io qui est un service qui génère automatiquement des paquets polyfill basés sur la chaîne UserAgent du navigateur de l'utilisateur.

Les anciens navigateurs peuvent être pris en charge via @vitejs/plugin-legacy, qui génère automatiquement des chunks anciens et les polyfills correspondants pour les fonctionnalités du langage ES. Les chunks hérités sont chargés de manière conditionnelle uniquement dans les navigateurs qui n'ont pas de support ESM natif.

Chemin de base public #

• Relié : Gestion des actifs

Si vous déployez votre projet sous un chemin public imbriqué, spécifiez simplement l'option de configuration base et tous les chemins des ressources seront réécrits en conséquence. Cette option peut également être spécifiée en tant qu'option de ligne de commande, par exemple vite build --base=/my/public/path/.

Les URLs des ressources importées en JS, les références CSS url(), et les références des ressources dans vos fichiers .html sont toutes automatiquement ajustées pour respecter cette option pendant la construction.

L'exception est lorsque vous devez concaténer dynamiquement des URLs à la volée. Dans ce cas, vous pouvez utiliser la variable import.meta.env.BASE_URL injectée globalement qui sera le chemin de base public. Notez que cette variable est remplacée statiquement lors de la construction, elle doit donc apparaître exactement telle quelle (c'est-à-dire que import.meta.env['BASE_URL'] ne fonctionnera pas).

Pour un contrôle avancé du chemin de base, consultez Advanced Base Options.

Personnalisation de la compilation #

La compilation peut être personnalisée via diverses options de configuration de la compilation. Plus précisément, vous pouvez ajuster directement les options de rollup via build.rollupOptions :

// vite.config.js
export default defineConfig({
  build : {
    rollupOptions : {
      // https://rollupjs.org/guide/en/#big-list-of-options
    }
  }
})

Par exemple, vous pouvez spécifier plusieurs sorties Rollup avec des plugins qui ne sont appliqués que pendant la construction.

Stratégie de découpage #

Vous pouvez configurer la façon dont les chunks sont divisés en utilisant build.rollupOptions.output.manualChunks (voir Rollup docs). Jusqu'à Vite 2.8, la stratégie de découpage par défaut divisait les chunks en index et vendor. C'est une bonne stratégie pour certains SPAs, mais il est difficile de fournir une solution générale pour chaque cas d'utilisation de la cible Vite. A partir de Vite 2.9, manualChunks n'est plus modifié par défaut. Vous pouvez continuer à utiliser la stratégie Split Vendor Chunk en ajoutant le splitVendorChunkPlugin dans votre fichier de configuration :

// vite.config.js
import { splitVendorChunkPlugin } from 'vite'
export default defineConfig({
  plugins: [splitVendorChunkPlugin()]
})

Cette stratégie est également fournie en tant que fabrique splitVendorChunk({ cache : SplitVendorChunkCache }), au cas où une composition avec une logique personnalisée serait nécessaire. cache.reset() doit être appelé à buildStart pour que le mode veille de la construction fonctionne correctement dans ce cas.

Reconstruction sur les changements de fichiers #

Vous pouvez activer l'observateur de rollup avec vite build --watch. Ou, vous pouvez directement ajuster les WatcherOptions sous-jacents via build.watch :

// vite.config.js
export default defineConfig({
  build : {
    watch : {
      // https://rollupjs.org/guide/en/#watch-options
    }
  }
})

Avec le drapeau --watch activé, les changements apportés au fichier vite.config.js, ainsi qu'à tout fichier à regrouper, déclencheront une reconstruction.

Application multi-pages #

Supposons que vous ayez la structure de code source suivante :

├── package.json
├── vite.config.js
├─── index.html
├─── main.js
└─── imbriqué
    ├─── index.html
    └─── nested.js

Pendant le dev, il suffit de naviguer ou de créer un lien vers /nested/ - cela fonctionne comme prévu, comme pour un serveur de fichiers statiques normal.

Pendant la construction, tout ce que vous avez à faire est de spécifier plusieurs fichiers .html comme points d'entrée :

// vite.config.js
import { resolve } from 'path'
import { defineConfig } from 'vite'

export default defineConfig({
  build: {
    rollupOptions: {
      input: {
        main: resolve(__dirname, 'index.html'),
        nested: resolve(__dirname, 'nested/index.html')
      }
    }
  }
})

Si vous spécifiez une autre racine, rappelez-vous que __dirname sera toujours le dossier de votre fichier vite.config.js lors de la résolution des chemins d'entrée. Par conséquent, vous devrez ajouter votre entrée root aux arguments de resolve.

Mode bibliothèque #

Lorsque vous développez une bibliothèque orientée navigateur, vous passez probablement la plupart du temps sur une page de test/démonstration qui importe votre bibliothèque actuelle. Avec Vite, vous pouvez utiliser votre index.html dans ce but pour obtenir une expérience de développement fluide.

Quand il est temps d'empaqueter votre bibliothèque pour la distribution, utilisez l'option de configuration build.lib. Assurez-vous d'externaliser toutes les dépendances que vous ne voulez pas regrouper dans votre bibliothèque, par exemple vue ou react :

// vite.config.js
import { resolve } from 'path'
import { defineConfig } from 'vite'

export default defineConfig({
  build: {
    lib: {
      // Could also be a dictionary or array of multiple entry points
      entry: resolve(__dirname, 'lib/main.js'),
      name: 'MyLib',
      // the proper extensions will be added
      fileName: 'my-lib'
    },
    rollupOptions: {
      // make sure to externalize deps that shouldn't be bundled
      // into your library
      external: ['vue'],
      output: {
        // Provide global variables to use in the UMD build
        // for externalized deps
        globals: {
          vue: 'Vue'
        }
      }
    }
  }
})

Le fichier d'entrée contient les exportations qui peuvent être importées par les utilisateurs de votre paquet :

// lib/main.js
import Foo from './Foo.vue'
import Bar from './Bar.vue'
export { Foo, Bar }

L'exécution de vite build avec cette configuration utilise un préréglage Rollup qui est orienté vers l'expédition de bibliothèques et produit deux formats de paquets : es et umd (configurable via build.lib) :

$ vite build
construction pour la production...
dist/my-lib.js 0.08 KiB / gzip : 0.07 KiB
dist/my-lib.umd.cjs 0.30 KiB / gzip : 0.16 KiB

Le package.json recommandé pour votre lib :

{
  "name": "my-lib",
  "type": "module",
  "files": ["dist"],
  "main": "./dist/my-lib.umd.cjs",
  "module": "./dist/my-lib.js",
  "exports": {
    ".": {
      "import": "./dist/my-lib.js",
      "require": "./dist/my-lib.umd.cjs"
    }
  }
}

Ou, si vous exposez plusieurs points d'entrée :

{
  "name": "my-lib",
  "type": "module",
  "files": ["dist"],
  "main": "./dist/my-lib.cjs",
  "module": "./dist/my-lib.mjs",
  "exports": {
    ".": {
      "import": "./dist/my-lib.mjs",
      "require": "./dist/my-lib.cjs"
    },
    "./secondary": {
      "import": "./dist/secondary.mjs",
      "require": "./dist/secondary.cjs"
    }
  }
}

Options de base avancées #

Pour des cas d'utilisation avancés, les actifs déployés et les fichiers publics peuvent être dans des chemins différents, par exemple pour utiliser différentes stratégies de cache. Un utilisateur peut choisir de déployer dans trois chemins différents :

• les fichiers HTML d'entrée générés (qui peuvent être traités pendant le SSR)
• les actifs hachés générés (JS, CSS et autres types de fichiers comme les images)
• les [fichiers publics] copiés (assets.md#the-public-directory).

Une seule [base] statique (#public-base-path) n'est pas suffisante dans ces scénarios. Vite fournit un support expérimental pour les options de base avancées pendant la construction, en utilisant experimental.renderBuiltUrl.

experimental: {
  renderBuiltUrl(filename: string, { hostType }: { hostType: 'js' | 'css' | 'html' }) {
    if (hostType === 'js') {
      return { runtime: `window.__toCdnUrl(${JSON.stringify(filename)})` }
    } else {
      return { relative: true }
    }
  }
}

Si les actifs hachés et les fichiers publics ne sont pas déployés ensemble, les options pour chaque groupe peuvent être définies indépendamment en utilisant l'actif type inclus dans le second paramètre context donné à la fonction.

experimental: {
  renderBuiltUrl(filename: string, { hostId, hostType, type }: { hostId: string, hostType: 'js' | 'css' | 'html', type: 'public' | 'asset' }) {
    if (type === 'public') {
      return 'https://www.domain.com/' + filename
    }
    else if (path.extname(hostId) === '.js') {
      return { runtime: `window.__assetsPath(${JSON.stringify(filename)})` }
    }
    else {
      return 'https://cdn.domain.com/assets/' + filename
    }
  }
}