Funcionalidades
No nível mais básico, o desenvolvimento utilizando a Vite não é tão diferente da utilização de um servidor de ficheiro estático. No entanto, a Vite fornece muitas otimizações sobre as importações de ESM nativa para suportar várias funcionalidades que são normalmente vistas em configurações baseada em empacotador.
Resolução de Dependência de NPM e Pré-Empacotamento
As importações de ECMAScript nativas não suportam importações simples de módulo com a seguinte:
import { someMethod } from 'my-dep'
import { someMethod } from 'my-dep'
O exemplo acima lançará um erro no navegador. A Vite detetará tais importações simples de módulo em todos os ficheiros de fonte servidos e realizará o seguinte:
Pré-empacota-os para melhorar a velocidade de carregamento da página e converte módulos CommonJS / UMD para ESM. A etapa de pré-empacotamento é realizada com esbuild e torna o tempo de início frio da Vite significativamente mais rápido do que qualquer empacotador baseado em JavaScript.
Reescreve as importações para URLs válidas como
/node_modules/.vite/deps/my-dep.js?v=f3sf2ebd
para que o navegador possa importá-los apropriadamente.
As Dependências são Fortemente Cacheadas
A Vite cacheia as requisições de dependências através de cabeçalhos de HTTP, então se desejares editar ou depurar localmente uma dependência, siga as etapas aqui.
Substituição de Módulo Instantânea
A Vite fornece uma API de HMR sobre o ESM nativo. As abstrações com compatibilidades de HMR podem influenciar a API para fornecer atualizações precisas e instantâneas sem o recarregamento da página ou sem matar o estado da aplicação. A Vite oferece integrações de HMR de primeira classe para Componentes de Ficheiro Único de Vue e Atualização Rápida de React. Existem também integrações oficiais para Preact através do @prefresh/vite.
Nota que não precisas de manualmente definir estes - quando criares uma aplicação através de create-vite
, os modelos selecionados já teriam estes pré-configurados para ti.
TypeScript
A Vite suporta a importação de ficheiros .ts
fora da caixa.
Tradução de Código Apenas
Nota que a Vite apenas realiza a tradução de código sobre os ficheiros .ts
e NÃO realiza a verificação de tipo. Ela presume que a verificação de tipo está sendo cuidada pela tua IDE e processo de construção.
A razão da Vite não realizar a verificação de tipo como parte do processo de transformação é porque estes dois trabalhos funcionam fundamentalmente de maneiras diferentes. A tradução de código pode funcionar sobre uma base por ficheiro e alinha perfeitamente com modelo de compilação sobre demanda da Vite. Em comparação, a verificação de tipo requer conhecimento do grafo do módulo inteiro. Calçar a verificação de tipo em uma conduta de transformação da Vite inevitavelmente comprometerá os benefícios de velocidade da Vite.
O trabalho da Vite é receber os módulos do teu código-fonte em uma forma que possa executar no navegador o mais rápido possível. Para este fim, recomendamos separar as verificações de analises estáticas da conduta de transformação da Vite. Este princípio aplica-se aos outros verificadores de analises estáticas tais como ESLint.
Para as construções de produção, podes executar
tsc --noEmit
em adição ao comando de construçãobuild
da Vite.Durante o desenvolvimento, se precisares de mais do que as sugestões da IDE, recomendamos executar
tsc --noEmit --watch
em um processo separado, ou usar vite-plugin-checker se preferires ter erros de tipo diretamente reportados no navegador.
A Vite usa a esbuild para traduzir o código de TypeScript para JavaScript o qual é 20~30x mais rápido do que o tsc
puro, as atualizações de HMR podem refletir no navegador em menos de 50ms.
Use a sintaxe de Importações e Exportações de Tipo Apenas para evitar potenciais problemas tal como importações de tipo apenas sendo incorretamente empacotada, por exemplo:
import type { T } from 'only/types'
export type { T }
import type { T } from 'only/types'
export type { T }
Opções do Compilador da TypeScript
Alguns campos de configuração sob compilerOptions
no tsconfig.json
exige especial atenção.
isolatedModules
Deve ser definido para true
.
É porque esbuild
só realiza tradução de código sem informação de tipo, ela não suporta certas funcionalidades tais como importações implícitas de apenas tipo, constantes e enumerações.
Tu deves definir "isolatedModules": true
no teu tsconfig.json
sob compilerOptions
, assim a TypeScript alertar-te-á contra as funcionalidades que não funcionam com a tradução de código isolada.
No entanto, algumas bibliotecas (por exemplo, a vue
) não funciona bem com "isolatedModules": true
. Tu podes utilizar "skipLibCheck": true
para suprimir temporariamente os erros até ser corrigido corrente acima.
useDefineForClassFields
A partir da Vite 2.5.0, o valor padrão será true
se o alvo de TypeScript for ESNext
ou ES2022
ou mais recente. É consistente com o comportamento da tsc
4.3.2 e adiante. É também o comportamento de tempo de execução da ECMASCript padrão.
Mas pode ser contra-intuitivo para aqueles chegando de outras linguagens de programação ou versões antigas da TypeScript. Tu podes ler mais a respeito da transição nas notas de lançamento da TypeScript 3.7.
Se estiveres a utilizar uma biblioteca que depende fortemente de campos de classe, por favor seja cuidadoso a respeito da utilização tencionada da biblioteca dela.
Muitas bibliotecas esperam "useDefineForClassFields": true
, tais como MobX.
Mas algumas bibliotecas não transitaram para este novo padrão ainda, incluindo lit-element
. Por favor defina explicitamente useDefineForClassFields
para false
nestes casos.
Outras Opções do Compilador Afetando o Resultado da Construção
Se a migração da tua base de código para "isolatedModules": true
for um esforço insuperável, talvez sejas capaz de dar a volta a isto com uma extensão de terceiro tal como rollup-plugin-friendly-type-imports. No entanto, esta abordagem não é oficialmente suportada pela Vite.
Tipos de Clientes
Os tipos padrão da Vite são para a sua API de Node.js. Para calçar o ambiente de código do lado do cliente em uma aplicação de Vite, adicione um ficheiro de declaração d.ts
:
/// <reference types="vite/client" />
/// <reference types="vite/client" />
Alternativamente, podes adicionar vite/client
ao compilerOptions.types
dentro do teu tsconfig.json
:
{
"compilerOptions": {
"types": ["vite/client"]
}
}
{
"compilerOptions": {
"types": ["vite/client"]
}
}
Isto fornecerá os seguintes calçados de tipo:
- Importações de recurso (por exemplo, importação de um ficheiro
.svg
) - Tipos para variáveis de ambiente injetadas para Vite sobre a
i
mport.meta.env - Tipos para a API de HMR sobre a
i
mport.meta.hot
Dica
Para sobrepor a tipagem padrão, adicione um ficheiro de declaração de tipo que contém os teus tipos. Então adicione a referência do tipo antes de vite/client
.
Por exemplo, para fazer a importação padrão de um componente *.svg
de React:
vite-env-override.d.ts
(o ficheiro que contém as tuas tipos):
declare module '*.svg' {
const content: React.FC<React.SVGProps<SVGElement>>
export default content
}
declare module '*.svg' {
const content: React.FC<React.SVGProps<SVGElement>>
export default content
}
O ficheiro contendo a referência para
vite/client
:ts/// <reference types="./vite-env-override.d.ts" /> /// <reference types="vite/client" />
/// <reference types="./vite-env-override.d.ts" /> /// <reference types="vite/client" />
Vue
A Vite fornece suporte a Vue de primeira classe:
- Suporte ao Componente de Ficheiro Único de Vue 3 através de @vitejs/plugin-vue
- Suporte a Extensão de Sintaxe de JavaScript de Vue 3 através de @vitejs/plugin-vue-jsx
- Suporte ao Componente de Ficheiro Único de Vue 2.7 através de @vitejs/plugin-vue2
- Suporte a Extensão de Sintaxe de JavaScript de Vue 2.7 através de @vitejs/vite-plugin-vue2-jsx
JSX
O ficheiros .jsx
e .tsx
são também suportados fora da caixa. A tradução de código JSX é também manipulada através da esbuild.
Os utilizadores de Vue devem utilizar a extensão @vitejs/plugin-vue-jsx oficial, a qual fornece funcionalidades especificas incluindo a HMR, resolução de componente global, diretivas e ranhuras.
Se não estiveres a utilizar a JSX com a React ou Vue, Os jsxFactory
e jsxFragment
personalizados podem ser configurados utilizando a opção esbuild
. Por exemplo para a Preact:
// vite.config.js
import { defineConfig } from 'vite'
export default defineConfig({
esbuild: {
jsxFactory: 'h',
jsxFragment: 'Fragment'
}
})
// vite.config.js
import { defineConfig } from 'vite'
export default defineConfig({
esbuild: {
jsxFactory: 'h',
jsxFragment: 'Fragment'
}
})
Mais detalhes na documentação da esbuild.
Tu podes injetar os auxiliares de JSX utilizando jsxInject
(que é uma opção apenas de Vite) para evitar importações manuais:
// vite.config.js
import { defineConfig } from 'vite'
export default defineConfig({
esbuild: {
jsxInject: `import React from 'react'`
}
})
// vite.config.js
import { defineConfig } from 'vite'
export default defineConfig({
esbuild: {
jsxInject: `import React from 'react'`
}
})
CSS
A importação de ficheiros .css
injetará o seu conteúdo para a página através dum marcador <style>
com suporte a substituição de módulo instantânea.
Incorporação e Rebaseamento de @import
A Vite está pré-configurada para suportar a incorporação de @import
de CSS através de postcss-import
. Os pseudónimos de Vite são também respeitados pela @import
de CSS. Além disto, todas referências de url()
de CSS, mesmo se os ficheiros importados estiverem em diretórios diferentes, são sempre automaticamente rebaseados para garantir a correção.
Os pseudónimos @import
e o rebaseamento de URL são também suportados para os ficheiros de Sass e Less (consulte Pré-processadores de CSS).
PostCSS
Se o projeto contiver configuração de PostCSS válida (qualquer formato suportado pela postcss-load-config, por exemplo, postcss.config.js
), ele será automaticamente aplicado a todas CSS importadas.
Módulos de CSS
Qualquer ficheiro de CSS terminando com .module.css
é considerado um ficheiro de módulos de CSS. A importação de tal ficheiro retornará objeto de módulo correspondente:
/* example.module.css */
.red {
color: red;
}
/* example.module.css */
.red {
color: red;
}
import classes from './example.module.css'
document.getElementById('foo').className = classes.red
import classes from './example.module.css'
document.getElementById('foo').className = classes.red
O comportamento de módulos de CSS pode ser configurado através da opção css.modules
.
Se css.modules.localsConvention
for definido para ativar locais em "camelCase" (por exemplo, localsConvention: 'camelCaseOnly'
), podes também usar as importações nomeadas:
// .apply-color -> applyColor
import { applyColor } from './example.module.css'
document.getElementById('foo').className = applyColor
// .apply-color -> applyColor
import { applyColor } from './example.module.css'
document.getElementById('foo').className = applyColor
Pré-processadores de CSS
Uma vez que a Vite mira os navegadores modernos apenas, é recomendado utilizar variáveis de CSS nativa com as extensões de PostCSS que implementam os rascunhos de CSSWG (por exemplo, postcss-nesting) e escrever CSS simples em conformidade com os padrões do futuro.
Isto dito, a Vite fornece suporte embutido para os ficheiros .scss
, .sass
, .less
, .styl
e .stylus
. Não é necessário instalar extensões especificas de Vite para elas, mas o pré-processador correspondente por si só deve ser instalado:
# .scss and .sass
npm add -D sass
# .less
npm add -D less
# .styl and .stylus
npm add -D stylus
# .scss and .sass
npm add -D sass
# .less
npm add -D less
# .styl and .stylus
npm add -D stylus
Se estiveres a utilizar componentes de ficheiro único de Vue, este também ativa automaticamente <style lang="sass">
e outros.
A Vite melhora a resolução de @import
para a Sass e Less para que os pseudónimos de Vite sejam também respeitados. Além disto, referências de url()
relativa dentro de ficheiros Sass ou Less importados que estão em diretórios diferentes do ficheiro de raiz são também rebaseados automaticamente para garantir a correção.
Os pseudónimo de @import
e o rebaseamento de url
não são suportados para Styles por causa das restrições da sua API.
Tu podes também utilizar os módulos de CSS combinados com os pré-processadores ao adicionar .module
antes da extensão do ficheiro, por exemplo style.module.scss
.
Desativando a injeção de CSS para página
A injeção automática de conteúdos de CSS pode ser desligada através da parâmetro de consulta ?inline
. Neste caso, a sequência de caracteres da CSS processada é retornada como exportação padrão do módulo como de costume, mas os estilos não são injetados para página.
import otherStyles from './bar.css?inline' // não será injetado na página
import otherStyles from './bar.css?inline' // não será injetado na página
NOTA
As importações padrão e nomeadas de ficheiros de CSS (por exemplo, import style from './foo.css'
) foram removias desde a Vite 5. Use a consulta ?inline
.
CSS Relâmpago
Desde a versão 4.4 da Vite, existe suporte experimental para CSS Relâmpago. Tu podes optar por esta opção adicionado css.transformer: 'lightningcss'
ao teu ficheiro de configuração e instalar a dependência lightningcss
opcional:
npm add -D lightningcss
npm add -D lightningcss
Caso ativada, os ficheiros de CSS serão processados pela CSS Relâmpago ao invés da PostCSS. Para configurá-la, podes passar as opções da CSS Relâmpago para a opção de configuração css.lightingcss
.
Para configurares os Módulos de CSS, usarás css.lightningcss.cssModules
ao invés de css.modules
(a qual configura a maneira que a PostCSS lida com os módulos de CSS).
Por padrão, a Vite usa a esbuild
para minificar a CSS. A CSS Relâmpago também pode ser usada como minificador de CSS com build.cssMinify: 'lightningcss'
.
NOTA
Os pré-processadores de CSS não são suportados quando usas a CSS relâmpago.
Recursos Estáticos
A importação de um recurso estático retornará URL pública resolvida quando ela for servida:
import imgUrl from './img.png'
document.getElementById('hero-img').src = imgUrl
import imgUrl from './img.png'
document.getElementById('hero-img').src = imgUrl
Consultas especiais podem modificar como os recursos são carregados:
// Carrega explicitamente os recursos como URL
import assetAsURL from './asset.js?url'
// Carrega explicitamente os recursos como URL
import assetAsURL from './asset.js?url'
// Carrega os recursos como sequências de caracteres
import assetAsString from './shader.glsl?raw'
// Carrega os recursos como sequências de caracteres
import assetAsString from './shader.glsl?raw'
// Carrega os Operários de Web
import Worker from './worker.js?worker'
// Carrega os Operários de Web
import Worker from './worker.js?worker'
// Os Operários de Web embutidos como sequências de caracteres
// de base64 em tempo de execução
import InlineWorker from './worker.js?worker&inline'
// Os Operários de Web embutidos como sequências de caracteres
// de base64 em tempo de execução
import InlineWorker from './worker.js?worker&inline'
Mais detalhes em Manipulação de Recurso Estático.
JSON
Os ficheiros de JSON podem ser importados diretamente - importações nomeadas são também suportadas:
// importa o objeto inteiro
import json from './example.json'
// importa um campo (field) de raiz como exportação nomeada -
// ajuda com sacudidura de árvore!
import { field } from './example.json'
// importa o objeto inteiro
import json from './example.json'
// importa um campo (field) de raiz como exportação nomeada -
// ajuda com sacudidura de árvore!
import { field } from './example.json'
Importação de Glob Como
A Vite suporta a importação de múltiplos módulos do sistema de ficheiro através da função i
especial:
const modules = import.meta.glob('./dir/*.js')
const modules = import.meta.glob('./dir/*.js')
O exemplo de cima será transformado no seguinte:
// código produzido pela vite
const modules = {
'./dir/foo.js': () => import('./dir/foo.js'),
'./dir/bar.js': () => import('./dir/bar.js')
}
// código produzido pela vite
const modules = {
'./dir/foo.js': () => import('./dir/foo.js'),
'./dir/bar.js': () => import('./dir/bar.js')
}
Tu podes depois iterar sobre as chaves do objeto modules
para acessar os módulos correspondente:
for (const path in modules) {
modules[path]().then((mod) => {
console.log(path, mod)
})
}
for (const path in modules) {
modules[path]().then((mod) => {
console.log(path, mod)
})
}
Os ficheiros correspondidos são por padrão preguiçosamente carregados através da importação dinâmica e serão divididos em pedaços separados durante a construção. Se preferires importar todos os módulos diretamente (por exemplo, dependendo dos efeitos colaterais nestes módulos para serem aplicados primeiro), podes passar { eager: true }
como segundo argumento:
const modules = import.meta.glob('./dir/*.js', { eager: true })
const modules = import.meta.glob('./dir/*.js', { eager: true })
O exemplo de cima será transformado no seguinte:
// código produzido pela 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
}
// código produzido pela 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
}
Importação de Glob Como
i
também suporta a importação de ficheiros como sequências de caracteres (semelhante a Importação de Recurso como Sequência de Caracteres) com a sintaxe de Reflexão de Importação:
const modules = import.meta.glob('./dir/*.js', { as: 'raw', eager: true })
const modules = import.meta.glob('./dir/*.js', { as: 'raw', eager: true })
O exemplo de cima será transformado no seguinte:
// código produzido pela vite
const modules = {
'./dir/foo.js': 'export default "foo"\n',
'./dir/bar.js': 'export default "bar"\n'
}
// código produzido pela vite
const modules = {
'./dir/foo.js': 'export default "foo"\n',
'./dir/bar.js': 'export default "bar"\n'
}
{ as: 'url' }
é também suportado para de carregamento de recursos como URLs.
Padrões Diversificado
O primeiro argumento pode ser um arranjo de globs, por exemplo:
const modules = import.meta.glob(['./dir/*.js', './another/*.js'])
const modules = import.meta.glob(['./dir/*.js', './another/*.js'])
Padrões Negativos
Os padrões de glob negativo são também suportados (prefixados com !
). Para ignorar alguns ficheiros do resultado, podes adicionar os padrões glob de exclusão ao primeiro argumento:
const modules = import.meta.glob(['./dir/*.js', '!**/bar.js'])
const modules = import.meta.glob(['./dir/*.js', '!**/bar.js'])
// código produzido pela vite
const modules = {
'./dir/foo.js': () => import('./dir/foo.js')
}
// código produzido pela vite
const modules = {
'./dir/foo.js': () => import('./dir/foo.js')
}
Importações Nomeadas
É possível apenas importar partes dos módulos com as opções import
.
const modules = import.meta.glob('./dir/*.js', { import: 'setup' })
const modules = import.meta.glob('./dir/*.js', { import: 'setup' })
// código produzido pela 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)
}
// código produzido pela 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)
}
Quando combinada com eager
é até mesmo possível ter a sacudidura de árvore ativada para aqueles módulos.
const modules = import.meta.glob('./dir/*.js', { import: 'setup', eager: true })
const modules = import.meta.glob('./dir/*.js', { import: 'setup', eager: true })
// código produzido pela 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
}
// código produzido pela 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
}
Definir import
como default
para importar a exportação padrão.
const modules = import.meta.glob('./dir/*.js', {
import: 'default',
eager: true
})
const modules = import.meta.glob('./dir/*.js', {
import: 'default',
eager: true
})
// código produzido pela 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
}
// código produzido pela 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
}
Consultas Personalizadas
Tu podes também utilizar a opção query
para fornecer consultas personalizadas para as importações para outras extensões a consumir.
const modules = import.meta.glob('./dir/*.js', {
query: { foo: 'bar', bar: true }
})
const modules = import.meta.glob('./dir/*.js', {
query: { foo: 'bar', bar: true }
})
// código produzido pela vite
const modules = {
'./dir/foo.js': () =>
import('./dir/foo.js?foo=bar&bar=true'),
'./dir/bar.js': () =>
import('./dir/bar.js?foo=bar&bar=true')
}
// código produzido pela vite
const modules = {
'./dir/foo.js': () =>
import('./dir/foo.js?foo=bar&bar=true'),
'./dir/bar.js': () =>
import('./dir/bar.js?foo=bar&bar=true')
}
Advertências de Importação de Glob
Nota que:
- Isto é uma funcionalidade apenas para Vite e não é um padrão de Web ou ECMAScript.
- Os padrões glob são tratados como especificadores de importação: eles deve ser tanto relativos (começar com
./
) ou absolutos (começar com/
, resolvidos como sendo relativos a raiz do projeto) ou um caminho de pseudónimo (consulte a opçãoresolve.alias
). - O glob correspondente é feito através de
fast-glob
- consulte a sua documentação por padrões de glob suportados. - Tu deves também estar ciente de que todos os argumentos na
i
devem ser passados como literais. Tu NÃO podes utilizar as variáveis ou as expressões nelas.mport.meta.glob
Importação Dinâmica
Semelhante a importação de glob, a Vite também suporta importação dinâmica com as variáveis.
const module = await import(`./dir/${file}.js`)
const module = await import(`./dir/${file}.js`)
Nota que as variáveis apenas representam os nomes de ficheiro um nível de profundidade. Se file
for 'foo/bar'
, a importação falharia. Para utilização mais avançada, podes utilizar a funcionalidade de importação de glob.
WebAssembly
Os ficheiros .wasm
pré-compilados podem ser importados com ?init
. A exportação padrão será uma função de inicialização que retorna uma promessa da WebAssembly.Instance
:
import init from './example.wasm?init'
init().then((instance) => {
instance.exports.test()
})
import init from './example.wasm?init'
init().then((instance) => {
instance.exports.test()
})
A função de inicialização também pode receber um ImportObject
que é passado para WebAssembly.instantiate
como seu segundo argumento:
init({
imports: {
someFunc: () => {
/* ... */
}
}
}).then(() => {
/* ... */
})
init({
imports: {
someFunc: () => {
/* ... */
}
}
}).then(() => {
/* ... */
})
Na construção de produção, os ficheiros .wasm
mas pequenos do que o assetInlineLimit
serão embutidos como sequências de caracteres de base64. De outro modo, serão tratados como um recurso estático e requisitado sobre demanda.
NOTA
Proposta de Integração de Módulo de ECMAScript para WebAssembly não é atualmente suportada. Utilize vite-plugin-wasm
ou outras extensões da comunidade para lidar com isto.
Acessando o Módulo WebAssembly
Se precisarmos de acesso ao objeto Module
, por exemplo, para instância-lo várias vezes, usaremos uma importação de URL explícita para resolver o recurso, e depois realizar a instanciação:
import wasmUrl from 'foo.wasm?url'
const main = async () => {
const responsePromise = fetch(wasmUrl)
const { module, instance } = await WebAssembly.instantiateStreaming(
responsePromise,
)
/* ... */
}
main()
import wasmUrl from 'foo.wasm?url'
const main = async () => {
const responsePromise = fetch(wasmUrl)
const { module, instance } = await WebAssembly.instantiateStreaming(
responsePromise,
)
/* ... */
}
main()
Requisitando o Módulo na Node.js
Na interpretação no lado do servidor, a fetch()
acontecendo como parte da importação ?init
, pode falhar com TypeError: Invalid URL
. Consulte a questão Suportar wasm
na SSR.
Cá está uma alternativa, assumindo que a base do projeto é o diretório atual:
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()
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()
Operários de Web
Importar com Construtores
Um programa de operário de web pode ser importado utilizando new Worker()
e new SharedWorker()
. Comparado aos sufixos de operário, esta sintaxe encontra-se mais próxima dos padrões e é a maneira recomendado para criar operários.
const worker = new Worker(new URL('./worker.js', import.meta.url))
const worker = new Worker(new URL('./worker.js', import.meta.url))
O construtor operário também aceita opções, que podem ser utilizadas para criar operários de "módulo" (module, em Inglês):
const worker = new Worker(new URL('./worker.js', import.meta.url), {
type: 'module'
})
const worker = new Worker(new URL('./worker.js', import.meta.url), {
type: 'module'
})
Importar com Sufixos de Consulta
Um programa operário de web pode ser diretamente importado adicionando ?worker
ou ?sharedworker
para a requisição de importação. A exportação padrão será um construtor de operário personalizado:
import MyWorker from './worker?worker'
const worker = new MyWorker()
import MyWorker from './worker?worker'
const worker = new MyWorker()
O programa operário pode também utilizar declarações de import
no lugar de importScripts()
. Nota: durante o desenvolvimento isto depende do suporte nativo do navegador, mas para a construção de produção é compilado fora.
Por padrão, o programa operário será emitido como um pedaço separado na construção de produção. Se desejares embutir o operário como sequências de caracteres de base64, adicione a consulta inline
:
import MyWorker from './worker?worker&inline'
import MyWorker from './worker?worker&inline'
Se desejares recuperar o operário como uma URL, adicione a consulta url
:
import MyWorker from './worker?worker&url'
import MyWorker from './worker?worker&url'
Consulte as Opções de Operário por detalhes a respeito da configuração do empacotamento de todos operários.
Otimizações de Construção
As funcionalidades listadas abaixo são automaticamente aplicadas como parte do processo de construção e não precisam de configuração explícita a menos que queiras desativá-las.
Separação de Código de CSS
A Vite extrai automaticamente a CSS utilizada pelos módulos em um pedaço assíncrono e gera um ficheiro separado para ela. O ficheiro de CSS é carregado automaticamente através do marcador <link>
quando o pedaço assíncrono associado for carregado, e o pedaço assíncrono tem a garantia de apenas ser avaliada depois da CSS for carregada para evitar FOUC.
Se preferires ter todas as CSS extraídas em um único ficheiro, podes desativar a separação de código de CSS definindo build.cssCodeSplit
para false
.
Geração de Diretivas de Pré-Carregamento
A Vite gera automaticamente as diretivas <link rel="modulepreload">
para os pedaços de entrada e suas importações direta no HTML construído:
Otimização de Carregamento de Pedaço Assíncrono
Nas aplicações do mundo real, a Rollup frequentemente gera pedaços "comuns" - código que é partilhado entre dois ou mais pedaços. Combinado com as importações dinâmica, é muito comum ter o seguinte cenário:
Nos cenários não otimizados, quando o pedaço assíncrono A
é importado, o navegador terá de requisitar e analisar A
antes de poder compreender que também precisa do pedaço comum C
. Isto resultada e uma viagem de ida e volta na rede adicional:
Entry ---> A ---> C
Entry ---> A ---> C
A Vite reescreve automaticamente chamadas de importação dinâmica de separação de código com uma etapa de pré-carregamento para quando A
for requisitada, C
é requisitada em paralelo:
Entry ---> (A + C)
Entry ---> (A + C)
É possível para C
ter mais importações, que resultarão em mais viagens de ida e volta no cenário não otimizado. A otimização da Vite rastreará todas importações diretas para eliminar completamente as viagens de ida e volta independentemente da profundidade da importação.