Funktionen
Auf grundlegender Ebene ist die Entwicklung mit Vite nicht sehr unterschiedlich von der Verwendung eines statischen Dateiservers. Allerdings bietet Vite viele Verbesserungen gegenüber nativen ESM-Imports, um verschiedene Funktionen zu unterstützen, die in typischen Konfigurationen mit Build-Tools zu finden sind.
Auflösen und Vorab-Bündeln von NPM-Abhängigkeiten
Native ES-Imports unterstützen keine sogenannten "bare module imports" wie folgendes Beispiel:
import { someMethod } from 'my-dep'
Dieser Code führt im Browser zu einem Fehler. Vite erkennt solche "bare module imports" in allen bereitgestellten Quelldateien und führt die folgenden Schritte aus:
Vorab-Bündeln, um die Ladezeit der Seite zu verbessern und CommonJS / UMD-Module in ESM umzuwandeln. Der Vorab-Bündelungsschritt wird mit esbuild durchgeführt und macht Vites Startzeit deutlich schneller als bei jedem auf JavaScript basierenden Build-Tool.
Ändern der Imports in gültige URLs wie
/node_modules/.vite/deps/my-dep.js?v=f3sf2ebd
, damit der Browser sie ordnungsgemäß importieren kann.
Abhängigkeiten werden stark zwischengespeichert
Vite zwischenspeichert Abhängigkeitsanfragen über HTTP-Header. Wenn Sie also eine Abhängigkeit lokal bearbeiten/fehlerbeheben möchten, befolgen Sie die Schritte hier.
Hot Module Replacement (HMR)
Vite bietet eine HMR-API über nativen ESM. Frameworks mit HMR-Fähigkeiten können diese API nutzen, um sofortige und präzise Aktualisierungen ohne Neuladen der Seite oder Verlust des Anwendungsstatus bereitzustellen. Vite bietet First-Party-HMR-Integrationen für Vue Single File Components und React Fast Refresh. Es gibt auch offizielle Integrationen für Preact über @prefresh/vite.
Beachten Sie, dass Sie diese nicht manuell einrichten müssen - wenn Sie eine App über create-vite
erstellen, sind diese Vorlagen bereits für Sie vorconfiguriert.
TypeScript
Vite unterstützt das Importieren von .ts
-Dateien von Haus aus.
Nur Transpilation
Beachten Sie, dass Vite nur Transpilierung für .ts
-Dateien durchführt und keine Typüberprüfung durchführt. Es geht davon aus, dass die Typüberprüfung von Ihrer IDE und Ihrem Build-Prozess durchgeführt wird.
Der Grund, warum Vite die Typüberprüfung nicht im Rahmen des Transformationsprozesses durchführt, ist, dass diese beiden Aufgaben grundlegend unterschiedlich arbeiten. Transpilation kann auf Dateiebene arbeiten und passt perfekt zum on-demand-Kompiliermodell von Vite. Im Vergleich dazu erfordert die Typüberprüfung Kenntnisse über den gesamten Modulgraphen. Das Hineinzwängen der Typüberprüfung in den Transformationsprozess von Vite wird zwangsläufig die Geschwindigkeitsvorteile von Vite beeinträchtigen.
Vites Aufgabe ist es, Ihre Quellmodule so schnell wie möglich in eine Form zu bringen, die im Browser ausgeführt werden kann. Zu diesem Zweck empfehlen wir, statische Analyseprüfungen aus dem Transformationsprozess von Vite auszulagern. Dieses Prinzip gilt auch für andere statische Analyseprüfungen wie ESLint.
Für Production-Builds können Sie den Befehl
tsc --noEmit
zusätzlich zum Build-Befehl von Vite ausführen.Während der Entwicklung, wenn Sie mehr als nur IDE-Hinweise benötigen, empfehlen wir das Ausführen von
tsc --noEmit --watch
in einem separaten Prozess oder die Verwendung von vite-plugin-checker, wenn Sie Typfehler direkt im Browser gemeldet haben möchten.
Vite verwendet esbuild, um TypeScript in JavaScript zu transpilieren, was etwa 20-30-mal schneller ist als das native tsc
, und HMR-Updates können in weniger als 50 ms im Browser reflektiert werden.
Verwenden Sie die Type-Only Imports and Export-Syntax, um potenzielle Probleme wie falsche Bündelung von nur-Typ-Imports zu vermeiden, zum Beispiel:
import type { T } from 'only/types'
export type { T }
TypeScript Compiler-Optionen
Einige Konfigurationsfelder unter compilerOptions
in tsconfig.json
erfordern besondere Aufmerksamkeit.
isolatedModules
Sollte auf true
gesetzt werden.
Der Grund dafür ist, dass esbuild
nur die Transpilierung ohne Typinformationen durchführt und bestimmte Funktionen wie const enum
und implizite nur-Typen-Imports nicht unterstützt.
Sie müssen "isolatedModules": true
in Ihrer tsconfig.json
unter compilerOptions
festlegen, damit TypeScript Sie vor den Funktionen warnt, die nicht mit isolierter Transpilierung funktionieren.
Einige Bibliotheken (z.B. vue
) funktionieren jedoch nicht gut mit "isolatedModules": true
. In solchen Fällen können Sie "skipLibCheck": true
verwenden, um die Fehler vorübergehend zu unterdrücken, bis sie behoben sind.
useDefineForClassFields
Ab Vite 2.5.0 wird der Standardwert true
sein, wenn das TypeScript-Ziel ESNext
oder ES2022
oder neuer ist. Es ist konsistent mit dem Verhalten von tsc
4.3.2 und später. Es ist auch das Standardverhalten der ECMAScript-Laufzeit.
Andere TypeScript-Ziele werden standardmäßig auf false
gesetzt.
Aber es kann für diejenigen, die von anderen Programmiersprachen oder älteren Versionen von TypeScript kommen, kontraintuitiv sein. Weitere Informationen über den Übergang finden Sie in den TypeScript 3.7 release notes.
Wenn Sie eine Bibliothek verwenden, die sich stark auf Klassenfelder stützt, achten Sie bitte auf die beabsichtigte Verwendung dieser Felder durch die Bibliothek.
Die meisten Bibliotheken erwarten "useDefineForClassFields": true
, wie zum Beispiel MobX.
Aber ein paar Bibliotheken sind noch nicht zu diesem neuen Standard übergegangen, einschließlich lit-element
. Bitte setzen Sie in diesen Fällen useDefineForClassFields
explizit auf false
.
target
Vite transpiliert TypeScript standardmäßig nicht mit dem konfigurierten target
-Wert und folgt damit dem gleichen Verhalten wie esbuild
.
Stattdessen kann die Option esbuild.target
verwendet werden, die für eine minimale Transpilierung auf esnext
voreingestellt ist. Bei Builds hat die Option build.target
höhere Priorität und kann bei Bedarf ebenfalls gesetzt werden.
useDefineForClassFields
Wenn target
nicht ESNext
oder ES2022
oder neuer ist, oder wenn es keine tsconfig.json
Datei gibt, wird useDefineForClassFields
standardmäßig auf false
gesetzt, was mit dem Standardwert esbuild.target
von esnext
problematisch sein kann. Es kann zu statischen Initialisierungsblöcken transpilieren, was in Ihrem Browser möglicherweise nicht unterstützt wird.
Es wird daher empfohlen, target
auf ESNext
oder ES2022
oder neuer zu setzen, oder useDefineForClassFields
bei der Konfiguration von tsconfig.json
explizit auf true
zu setzen.
Andere Compiler-Optionen, die das Build-Ergebnis beeinflussen
Erweiterungen
importsNotUsedAsValues
preserveValueImports
verbatimModuleSyntax
jsx
jsxFactory
jsxFragmentFactory
jsxImportSource
experimentalDecorators
alwaysStrict
skipLibCheck
Vite-Start-Vorlagen haben "skipLibCheck": "true"
gesetzt, um die Überprüfung von Abhängigkeiten zu vermeiden, da sie möglicherweise nur bestimmte Versionen und Konfigurationen von TypeScript unterstützen. Mehr dazu erfahren Sie unter vuejs/vue-cli#5688.
Client-Typen
Die Standardtypen von Vite sind für die Node.js-API. Um die Umgebung von clientseitigem Code in einer Vite-Anwendung zu optimieren, fügen Sie eine Deklarationsdatei d.ts
hinzu:
/// <reference types="vite/client" />
Alternativ können Sie vite/client
zu compilerOptions.types
in tsconfig.json
hinzufügen:
{
"compilerOptions": {
"types": ["vite/client"]
}
}
Damit werden die folgenden Arten von Shims bereitgestellt:
- Asset-Importe (z.B. Importieren einer
.svg
-Datei) - Typen für die in Vite eingefügten env-Variablen auf
import.meta.env
- Typen für die HMR-API unter
import.meta.hot
TIP
Um die Standardtypisierung außer Kraft zu setzen, fügen Sie eine Typdefinitionsdatei hinzu, die Ihre Typisierungen enthält. Fügen Sie dann die Typreferenz vor "vite/client" ein.
Zum Beispiel, um den Standardimport von *.svg
zu einer React-Komponente zu machen:
vite-env-override.d.ts
(die Datei, die Ihre Eingaben enthält):tsdeclare module '*.svg' { const content: React.FC<React.SVGProps<SVGElement>> export default content }
- Die Datei, die den Verweis auf
vite/client
enthält:ts/// <reference types="./vite-env-override.d.ts" /> /// <reference types="vite/client" />
Vue
Vite bietet First-Class Vue Support:
- Vue 3 SFC Unterstützung über @vitejs/plugin-vue
- Ansicht 3 JSX Unterstützung via @vitejs/plugin-vue-jsx
- Ansicht 2.7 Unterstützung über @vitejs/plugin-vue2
- Ansicht <2.7 Unterstützung via vite-plugin-vue2
JSX
.jsx"- und "tsx"-Dateien werden ebenfalls von Haus aus unterstützt. JSX Transpilierung wird auch über esbuild gehandhabt.
Vue-Benutzer sollten das offizielle @vitejs/plugin-vue-jsx Plugin verwenden, das Vue 3-spezifische Funktionen wie HMR, globale Komponentenauflösung, Direktiven und Slots bietet.
Wenn JSX ohne React oder Vue verwendet wird, können benutzerdefinierte jsxFactory
und jsxFragment
mit der esbuild
Option konfiguriert werden. Zum Beispiel für Preact:
// vite.config.js
import { defineConfig } from 'vite'
export default defineConfig({
esbuild: {
jsxFactory: 'h',
jsxFragment: 'Fragment'
}
})
Mehr Details in esbuild docs.
Sie können die JSX-Helfer mit jsxInject
injizieren (eine Option, die nur für Vite verfügbar ist), um manuelle Importe zu vermeiden:
// vite.config.js
import { defineConfig } from 'vite'
export default defineConfig({
esbuild: {
jsxInject: `import React from 'react'`
}
})
CSS
Der Import von .css
-Dateien fügt deren Inhalt über ein <style>
-Tag mit HMR-Unterstützung in die Seite ein.
@import
Inlining und Rebasing
Vite ist vorkonfiguriert, um CSS @import
Inlining über postcss-import
zu unterstützen. Vite-Aliase werden auch für CSS @import
respektiert. Darüber hinaus werden alle CSS url()
-Referenzen, auch wenn die importierten Dateien in verschiedenen Verzeichnissen liegen, immer automatisch umbasiert, um die Korrektheit zu gewährleisten.
@import
-Aliase und URL-Rebasing werden auch für Sass- und Less-Dateien unterstützt (siehe CSS Pre-processors).
PostCSS
Wenn das Projekt eine gültige PostCSS-Konfiguration enthält (ein beliebiges Format, das von postcss-load-config unterstützt wird, z. B. postcss.config.js
), wird diese automatisch auf alle importierten CSS angewendet.
Beachten Sie, dass die CSS-Minifizierung nach PostCSS ausgeführt wird und die Option build.cssTarget
verwendet wird.
CSS-Module
Jede CSS-Datei, die mit .module.css
endet, wird als CSS-Modul-Datei betrachtet. Beim Importieren einer solchen Datei wird das entsprechende Modulobjekt zurückgegeben:
/* example.module.css */
.red {
color: red;
}
import classes from './example.module.css'
document.getElementById('foo').className = classes.red
Das Verhalten von CSS-Modulen kann über die Option css.modules
konfiguriert werden.
Wenn css.modules.localsConvention
so eingestellt ist, dass camelCase locals aktiviert sind (z.B. localsConvention: 'camelCaseOnly'
), können Sie auch benannte Importe verwenden:
// .apply-color -> applyColor
import { applyColor } from './example.module.css'
document.getElementById('foo').className = applyColor
CSS-Präprozessoren
Da Vite nur auf moderne Browser abzielt, wird empfohlen, native CSS-Variablen mit PostCSS-Plugins zu verwenden, die CSSWG-Entwürfe implementieren (z. B. postcss-nesting) und einfaches, den zukünftigen Standards entsprechendes CSS erstellen.
Abgesehen davon bietet Vite integrierte Unterstützung für .scss
, .sass
, .less
, .styl
und .stylus
Dateien. Es ist nicht notwendig, Vite-spezifische Plugins für diese Dateien zu installieren, aber der entsprechende Präprozessor selbst muss installiert sein:
# .scss and .sass
npm add -D sass
# .less
npm add -D less
# .styl and .stylus
npm add -D stylus
Bei der Verwendung von Vue-Einzeldateikomponenten aktiviert dies auch automatisch <style lang="sass">
und andere.
Vite verbessert die @import
-Auflösung für Sass und Less, so dass Vite-Aliase ebenfalls respektiert werden. Außerdem werden relative url()
-Referenzen innerhalb importierter Sass/Less-Dateien, die sich in anderen Verzeichnissen als die Stammdatei befinden, automatisch umgestellt, um die Korrektheit sicherzustellen.
@import
alias und url rebasing werden für Stylus aufgrund seiner API-Beschränkungen nicht unterstützt.
Sie können auch CSS-Module in Kombination mit Präprozessoren verwenden, indem Sie der Dateierweiterung .module
voranstellen, zum Beispiel style.module.scss
.
Deaktivieren der CSS-Injektion in die Seite
Die automatische Injektion von CSS-Inhalten kann über den Abfrageparameter ?inline
ausgeschaltet werden. In diesem Fall wird der verarbeitete CSS-String wie üblich als Standard-Export des Moduls zurückgegeben, aber die Stile werden nicht in die Seite injiziert.
import styles from './foo.css' // will be injected into the page
import otherStyles from './bar.css?inline' // will not be injected
HINWEIS
Standard- und benannte Importe aus CSS-Dateien (z.B. import style from './foo.css'
) sind seit Vite 5 veraltet. Verwenden Sie stattdessen die ?inline
-Query-Komponente.
Lightning CSS
Ab Vite 4.4 gibt es eine experimentelle Unterstützung für Lightning CSS. Sie können sich dafür entscheiden, indem Sie css.transformer: 'lightningcss'
zu Ihrer Konfigurationsdatei hinzufügen und die optionale Abhängigkeit von lightningcss
installieren:
npm add -D lightningcss
Wenn diese Option aktiviert ist, werden CSS-Dateien von Lightning CSS anstelle von PostCSS verarbeitet. Um dies zu konfigurieren, können Sie Lightning CSS-Optionen an die Konfigurationsoption css.lightningcss
übergeben.
Um CSS-Module zu konfigurieren, verwenden Sie css.lightningcss.cssModules
anstelle von css.modules
(die die Art und Weise konfiguriert, wie PostCSS CSS-Module behandelt).
Standardmäßig verwendet Vite esbuild zum Minifizieren von CSS. Lightning CSS kann auch als CSS-Minifizierer mit build.cssMinify: 'lightningcss'
verwendet werden.
HINWEIS
CSS-Präprozessoren werden bei der Verwendung von Lightning CSS nicht unterstützt.
Statische Assets
Beim Importieren eines statischen Assets wird die aufgelöste öffentliche URL zurückgegeben, wenn es bereitgestellt wird:
import imgUrl from './img.png'
document.getElementById('hero-img').src = imgUrl
Spezielle Abfragen können die Art und Weise, wie Assets geladen werden, verändern:
// Explicitly load assets as URL
import assetAsURL from './asset.js?url'
// Load assets as strings
import assetAsString from './shader.glsl?raw'
// Load Web Workers
import Worker from './worker.js?worker'
// Web Workers inlined as base64 strings at build time
import InlineWorker from './worker.js?worker&inline'
Weitere Einzelheiten unter Statische Vermögensverwaltung.
JSON
JSON-Dateien können direkt importiert werden - benannte Importe werden ebenfalls unterstützt:
// import the entire object
import json from './example.json'
// import a root field as named exports - helps with tree-shaking!
import { field } from './example.json'
Glob-Import
Vite unterstützt den Import von mehreren Modulen aus dem Dateisystem über die spezielle Funktion import.meta.glob
:
const modules = import.meta.glob('./dir/*.js')
Der obige Code wird in den folgenden Code umgewandelt:
// code produced by vite
const modules = {
'./dir/foo.js': () => import('./dir/foo.js'),
'./dir/bar.js': () => import('./dir/bar.js')
}
Sie können dann die Schlüssel des Objekts "Module" durchlaufen, um auf die entsprechenden Module zuzugreifen:
for (const path in modules) {
modules[path]().then((mod) => {
console.log(path, mod)
})
}
Übereinstimmende Dateien werden standardmäßig über den dynamischen Import nachgeladen und während des Builds in einzelne Teile aufgeteilt. Wenn Sie lieber alle Module direkt importieren möchten (z. B. im Vertrauen darauf, dass Seiteneffekte in diesen Modulen zuerst angewendet werden), können Sie { eager: true }
als zweites Argument übergeben:
const modules = import.meta.glob('./dir/*.js', { eager: true })
Der obige Code wird in den folgenden Code umgewandelt:
// code produced by vite
import * as __glob__0_0 from './dir/foo.js'
import * as __glob__0_1 from './dir/bar.js'
const modules = {
'./dir/foo.js': __glob__0_0,
'./dir/bar.js': __glob__0_1
}
Mehrere Patterns
Das erste Argument kann ein Array von Globs sein, zum Beispiel
const modules = import.meta.glob(['./dir/*.js', './another/*.js'])
Negative Patterns
Negative glob-Muster werden ebenfalls unterstützt (mit dem Präfix !
). Um einige Dateien aus dem Ergebnis zu ignorieren, können Sie dem ersten Argument "exclude glob patterns" hinzufügen:
const modules = import.meta.glob(['./dir/*.js', '!**/bar.js'])
// code produced by vite
const modules = {
'./dir/foo.js': () => import('./dir/foo.js')
}
Benannte Importe
Es ist möglich, nur Teile der Module mit den import
Optionen zu importieren.
const modules = import.meta.glob('./dir/*.js', { import: 'setup' })
// code produced by vite
const modules = {
'./dir/foo.js': () => import('./dir/foo.js').then((m) => m.setup),
'./dir/bar.js': () => import('./dir/bar.js').then((m) => m.setup)
}
In Kombination mit eager
ist es sogar möglich, das Tree-Shaking für diese Module zu aktivieren.
const modules = import.meta.glob('./dir/*.js', {
import: 'setup',
eager: true
})
// code produced by vite:
import { setup as __glob__0_0 } from './dir/foo.js'
import { setup as __glob__0_1 } from './dir/bar.js'
const modules = {
'./dir/foo.js': __glob__0_0,
'./dir/bar.js': __glob__0_1
}
Setzen Sie import
auf default
, um den Standard-Export zu importieren.
const modules = import.meta.glob('./dir/*.js', {
import: 'default',
eager: true
})
// code produced by vite:
import __glob__0_0 from './dir/foo.js'
import __glob__0_1 from './dir/bar.js'
const modules = {
'./dir/foo.js': __glob__0_0,
'./dir/bar.js': __glob__0_1
}
Benutzerdefinierte Abfragen
Sie können auch die Option query
verwenden, um Abfragen für Importe zu stellen, zum Beispiel um Assets als String oder als URL zu importieren:
const moduleStrings = import.meta.glob('./dir/*.svg', {
query: '?raw',
import: 'default',
})
const moduleUrls = import.meta.glob('./dir/*.svg', {
query: '?url',
import: 'default',
})
// code produced by vite:
const moduleStrings = {
'./dir/foo.svg': () => import('./dir/foo.js?raw').then((m) => m['default']),
'./dir/bar.svg': () => import('./dir/bar.js?raw').then((m) => m['default']),
}
const moduleUrls = {
'./dir/foo.svg': () => import('./dir/foo.js?url').then((m) => m['default']),
'./dir/bar.svg': () => import('./dir/bar.js?url').then((m) => m['default']),
}
You can also provide custom queries for other plugins to consume:
const modules = import.meta.glob('./dir/*.js', {
query: { foo: 'bar', bar: true }
})
Glob Import Caveats
Beachten Sie dies:
- Dies ist ein reines Vite-Feature und kein Web- oder ES-Standard.
- Die Glob-Muster werden wie Import-Spezifizierer behandelt: Sie müssen entweder relativ (beginnen mit
./
) oder absolut (beginnen mit/
, aufgelöst relativ zum Projektstamm) oder ein Alias-Pfad sein (siehe Optionresolve.alias
). - Der Glob-Abgleich erfolgt über
fast-glob
- sehen Sie sich die Dokumentation für unterstützte Glob-Muster an. - Sie sollten sich auch bewusst sein, dass alle Argumente in
import.meta.glob
als Literale übergeben werden müssen. Sie können KEINE Variablen oder Ausdrücke in ihnen verwenden.
Dynamischer Import
Ähnlich wie glob-import, unterstützt Vite auch den dynamischen Import mit Variablen.
const module = await import(`./dir/${file}.js`)
Beachten Sie, dass Variablen nur Dateinamen eine Ebene tiefer darstellen. Wenn file
'foo/bar'
ist, würde der Import fehlschlagen. Für fortgeschrittene Anwendungen können Sie die Funktion glob-import verwenden.
WebAssembly
Vorkompilierte .wasm
Dateien können mit ?init
importiert werden. Der Standardexport wird eine Initialisierungsfunktion sein, die ein Promise der WebAssembly.Instance
zurückgibt:
import init from './example.wasm?init'
init().then((instance) => {
instance.exports.test()
})
Die init-Funktion kann auch ein importObject annehmen, das als zweites Argument an WebAssembly.instantiate
weitergegeben wird:
init({
imports: {
someFunc: () => {
/* ... */
}
}
}).then(() => {
/* ... */
})
Im Produktions-Build werden .wasm
-Dateien, die kleiner als assetInlineLimit
sind, als base64-Strings inlined. Andernfalls werden sie wie ein statisches Asset behandelt und bei Bedarf abgerufen.
HINWEIS
ES Module Integration Proposal for WebAssembly wird derzeit nicht unterstützt. Verwenden Sie vite-plugin-wasm
oder andere Community-Plugins, um dies zu handhaben.
Zugriff auf das WebAssembly-Modul
Wenn Sie Zugriff auf das "Modul"-Objekt benötigen, z.B. um es mehrfach zu instanziieren, verwenden Sie einen expliziten URL-Import, um das Asset aufzulösen, und führen Sie dann die Instanziierung durch:
import wasmUrl from 'foo.wasm?url'
const main = async () => {
const responsePromise = fetch(wasmUrl)
const { module, instance } =
await WebAssembly.instantiateStreaming(responsePromise)
/* ... */
}
main()
Abrufen des Moduls in Node.js
In SSR kann das fetch()
Ereignis als Teil des ?init
Imports mit TypeError: Ungültige URL
fehlschlagen. Siehe das Problem Support wasm in SSR.
Hier ist eine Alternative, vorausgesetzt, die Projektbasis ist das aktuelle Verzeichnis:
import wasmUrl from 'foo.wasm?url'
import { readFile } from 'node:fs/promises'
const main = async () => {
const resolvedUrl = (await import('./test/boot.test.wasm?url')).default
const buffer = await readFile('.' + resolvedUrl)
const { instance } = await WebAssembly.instantiate(buffer, {
/* ... */
})
/* ... */
}
main()
Web Workers
Import mit Konstruktoren
Ein Web-Worker-Skript kann mit new Worker()
und new SharedWorker()
importiert werden. Im Vergleich zu den Worker-Suffixen lehnt sich diese Syntax näher an die Standards an und ist der empfohlene Weg, um Worker zu erstellen.
const worker = new Worker(new URL('./worker.js', import.meta.url))
Der Worker-Konstruktor akzeptiert auch Optionen, die verwendet werden können, um "Modul"-Arbeiter zu erstellen:
const worker = new Worker(new URL('./worker.js', import.meta.url), {
type: 'module'
})
Die Erkennung von Workern funktioniert nur, wenn der Konstruktor new URL()
direkt innerhalb der Deklaration new Worker()
verwendet wird. Außerdem müssen alle Optionsparameter statische Werte sein (d.h. String-Literale).
Import mit Abfrage-Suffixen
Ein Webworker-Skript kann direkt importiert werden, indem man ?worker
oder ?sharedworker
an die Importanfrage anhängt. Der Standard-Export ist ein eigener Worker-Konstruktor:
import MyWorker from './worker?worker'
const worker = new MyWorker()
Das Arbeitsskript kann auch ESM-import
-Anweisungen anstelle von ìmportScripts()`Ω verwenden. Anmerkung: Während der Entwicklung ist dies auf browser native support angewiesen, aber für den Produktions-Build wird es wegkompiliert.
Standardmäßig wird das Arbeitsskript als separater Chunk im Produktions-Build ausgegeben. Wenn Sie den Worker als base64-String einbinden möchten, fügen Sie die Abfrage inline
hinzu:
import MyWorker from './worker?worker&inline'
Wenn Sie den Worker als URL abrufen möchten, fügen Sie die Abfrage url
hinzu:
import MyWorker from './worker?worker&url'
See Worker Options for details on configuring the bundling of all workers.
Content Security Policy (CSP)
Für den Einsatz von CSP müssen aufgrund von Vite's Interna bestimmte Direktiven oder Configs gesetzt werden.
'nonce-{RANDOM}'
Falls html.cspNonce
gesetzt ist, fügt Vite ein nonce-Attribut mit dem angegebenen Wert zu allen <script>
- und <style>
-Tags sowie zu <link>
-Tags für Stylesheets und Modul-Preloading hinzu. Falls diese Option gesetzt ist, fügt Vite außerdem ein Meta-Tag ein (<meta property="csp-nonce" nonce="PLACEHOLDER" />
).
Der nonce-Wert eines Meta-Tags mit property="csp-nonce"
wird von Vite bei Bedarf sowohl während der Entwicklung als auch nach dem Build verwendet.
WARNING
Stellen Sie sicher, dass Sie den Platzhalter bei jeder Anfrage durch einen eindeutigen Wert ersetzen. Dies ist wichtig, um zu verhindern, dass die Richtlinie einer Ressource umgangen wird, was sonst leicht möglich wäre.
data:
By default, during build, Vite inlines small assets as data URIs. Allowing data:
for related directives (e.g. img-src
, font-src
), or, disabling it by setting build.assetsInlineLimit: 0
is necessary.
WARNING
Do not allow data:
for script-src
. It will allow injection of arbitrary scripts.
Build-Optimierungen
Die unten aufgeführten Funktionen werden automatisch als Teil des Build-Prozesses angewendet und müssen nicht explizit konfiguriert werden, es sei denn, Sie möchten sie deaktivieren.
CSS-Code-Aufteilung
Vite extrahiert automatisch das CSS, das von Modulen in einem asynchronen Chunk verwendet wird, und erzeugt dafür eine separate Datei. Die CSS-Datei wird automatisch über einen <link>
-Tag geladen, wenn der zugehörige asynchrone Chunk geladen wird, und der asynchrone Chunk wird garantiert erst ausgewertet, nachdem das CSS geladen wurde, um FOUC zu vermeiden.
Wenn Sie das gesamte CSS lieber in eine einzige Datei extrahiert haben möchten, können Sie die Aufteilung des CSS-Codes deaktivieren, indem Sie build.cssCodeSplit
auf false
setzen.
Generierung von Preload-Direktiven
Vite generiert automatisch <link rel="modulepreload">
Direktiven für Eintrags-Chunks und deren direkte Importe in der erstellten HTML.
Asynchrones Laden von Chunks Optimierung
In realen Anwendungen erzeugt Rollup oft "gemeinsame" Chunks - Code, der von zwei oder mehreren anderen Chunks gemeinsam genutzt wird. In Kombination mit dynamischen Importen kommt es häufig zu folgendem Szenario:
In den nicht optimierten Szenarien muss der Browser beim Import des asynchronen Chunks "A" zunächst "A" anfordern und analysieren, bevor er herausfinden kann, dass er auch den gemeinsamen Chunk "C" benötigt. Dies führt zu einem zusätzlichen Netzwerk-Roundtrip:
Entry ---> A ---> C
Vite schreibt automatisch Code-getrennte dynamische Importaufrufe mit einem Vorladeschritt um, so dass, wenn "A" angefordert wird, "C" parallel abgerufen wird:
Entry ---> (A + C)
Es ist möglich, dass "C" weitere Importe hat, was im nicht optimierten Szenario zu noch mehr Roundtrips führen würde. Die Optimierung von Vite verfolgt alle direkten Importe, um die Roundtrips unabhängig von der Importtiefe vollständig zu eliminieren.