Funcionalidades

No nível mais básico, o desenvolvimento usando a Vite não é diferente de usar um servidor de ficheiro estático. No entanto, a Vite fornece muitas otimizações sobre as importações nativas de Módulo de ECMAScript para suportar várias funcionalidades que são normalmente vistas nas configurações baseadas em empacotador.

Resolução de Dependência de NPM e Pré-Empacotamento

As importações nativas da ECMAScript não suportam importações simples de módulo como o seguinte:

import { someMethod } from 'my-dep'

O exemplo acima acionará um erro no navegador. A Vite detetará tais importações simples de módulo em todos os ficheiros do código-fonte servido e realizará o seguinte:

1. Pré-empacotará os módulos para melhorar a velocidade do carregamento da página e converterá os módulos de CommonJS ou UMD em Módulo de ECMAScript. A etapa de pré-empacotamento é realizada com a esbuild e torna a inicialização fria da Vite significativamente mais rápida do que qualquer empacotador baseado na JavaScript.

2. Reescreverá as importações para URLs válidas como /node_modules/.vite/deps/my-dep.js?v=f3sf2ebd para que o navegador possa importá-los corretamente.

As Dependências são Fortemente Armazenadas para Consulta Imediata

A Vite armazena para consulta imediata as requisições de dependência através dos cabeçalhos de HTTP, assim se desejarmos editar ou depurar uma dependência localmente, devemos seguir os passos que estão nesta ligação.

Substituição de Módulo Instantânea

A Vite fornece uma API de Substituição de Módulo Instantânea sobre o Módulo de ECMAScript nativo. As abstrações com as capacidades de substituição de módulo instantânea podem influenciar a API para fornecer atualizações precisas e instantâneas sem recarregar a página ou desperdiçar o estado da aplicação. A Vite fornece integrações de substituição de módulo instantânea de primeiro partido para os Componentes de Ficheiro Único da Vue e as Atualizações Rápidas da React. Também existem integrações oficiais para a Preact através da @prefresh/vite.

Nota que não precisamos de as definir manualmente - quando críamos uma aplicação através da create-vite, os modelos de projetos selecionados já teriam estes pré-configurados para nós.

TypeScript

A Vite suporta a importação de ficheiros .ts fora da caixa.

Apenas Tradução de Código

Nota que a Vite apenas realiza a tradução do código sobre os ficheiros .ts e NÃO realiza a verificação de tipo. Esta supõe que a verificação de tipo está sendo realizada pelo nosso ambiente de desenvolvimento integrado e processo de construção.

A motivo pela qual a Vite não realiza verificação de tipo como parte do processo de transformação é porque as duas tarefas funcionam fundamentalmente de maneiras diferentes. A tradução de código pode aperfeiçoar uma base por ficheiro e alinhar-se perfeitamente com modelo de compilação sob demanda da Vite. Comparativamente, a verificação de tipo exige conhecimento do gráfico de módulo inteiro. A introdução da verificação de tipo na conduta de transformação da Vite comprometerá inevitavelmente as vantagens de velocidade da Vite.

O trabalho da Vite é receber os módulos do nosso código-fonte duma maneira que possa executar no navegador o mais rápido possível. Para este fim, recomendamos separar as verificações da analise estática da conduta de transformação da Vite. Este princípio aplica-se às outras verificações da analise estática, como a ESLint.

• Para as construções de produção, podemos executar a tsc --noEmit em adição ao comando de construção da Vite.

• Durante o desenvolvimento, se precisarmos de mais do que as sugestões do ambiente de desenvolvimento integrado, recomendamos executar tsc --noEmit --watch num processo separado, ou usar vite-plugin-checker se preferirmos ter erros de tipo diretamente reportados no navegador.

A Vite usa a esbuild para traduzir o código de TypeScript em JavaScript que é 20~30 vezes mais rápida do que a simples tsc, as atualizações da substituição de módulo instantânea podem refletir-se no navegador em menos de 50ms.

Usamos a sintaxe de importações e exportações exclusivamente por tipo para evitar potenciais problemas como importações exclusivamente por tipo sendo incorretamente empacotadas, por exemplo:

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 exigem atenção especial.

isolatedModules

• Documentação da TypeScript

Deve ser definida para true.

Isto porque a esbuild apenas realiza a tradução de código sem a informação do tipo, esta não suporta certas funcionalidades como enumerações constantes e importações exclusivamente por tipo implícitas.

Nós devemos definir "isolatedModules": true no nosso tsconfig.json sob a compilerOptions, para que a TypeScript avise-nos sobre as funcionalidade que não funcionam com a tradução isolada de código.

Se uma dependência não funcionar bem com a "isolatedModules": true. Nós podemos usar "skipLibCheck": true para suprimir temporariamente os erros até serem corrigidos corrente acima.

useDefineForClassFields

• Documentação da TypeScript

Desde a Vite 2.5.0, o valor padrão será true se o alvo da TypeScript for a ESNext ou ES2022 ou mais recente. Isto é consiste com o comportamento da tsc 4.3.2 e adiante. É também o comportamento de execução da ECMAScript padrão.

Os outros alvos da TypeScript predefinirão para false.

Mas pode ser contra-intuitivo para aqueles que vêm de outras linguagens de programação ou de versões mais antigas da TypeScript. Nós podemos ler mais sobre a transição nas notas de lançamento da TypeScript 3.7.

Se estivermos usando uma biblioteca que depende fortemente de campos da classe, temos que ter cuidado com o uso que a biblioteca tenciona dar-lhes.

Muitas bibliotecas esperam "useDefineForClassFields": true, tais como a MobX.

Mas algumas bibliotecas ainda não fizeram a transição para este novo padrão, incluindo a lit-element. Temos que definir explicitamente useDefineForClassFields para false nestes casos.

target

• Documentação da TypeScript

A Vite ignora o valor da target no tsconfig.json, seguindo o mesmo comportamento da esbuild.

Para especificar o alvo em desenvolvimento, a opção esbuild.target pode ser usada, a qual predefine para esnext para tradução de código minimalista. Nas construções, a opção build.target tem maior prioridade sobre a esbuild.target e também pode ser definida se necessária.

useDefineForClassFields

Se target não for ESNext ou ES2022 ou mais recente, ou se não existir nenhum ficheiro tsconfig.json, useDefineForClassFields predefinirá para false o que pode ser problemático com o valor padrão de esbuild.target de esnext. Esta pode traduzir o código para blocos de inicialização estática que pode não ser suportado no nosso navegador.

Como tal, é recomendado definir target para ESNext ou ES2022 ou mais recente, ou definir useDefineForClassFields para true explicitamente quando configuramos o tsconfig.json.

Outras Opções do Compilador que Afetam o Resultado da Construção

• extends
• importsNotUsedAsValues
• preserveValueImports
• verbatimModuleSyntax
• jsx
• jsxFactory
• jsxFragmentFactory
• jsxImportSource
• experimentalDecorators
• alwaysStrict

skipLibCheck

Os modelos de projeto iniciais da Vite têm "skipLibCheck": "true" por padrão para evitar dependências de verificação de tipo, uma vez que podem escolher apenas suportar versões e configurações específicas de TypeScript. Nós podemos aprender mais em vuejs/vue-cli#5688.

Tipos de Clientes

Os tipos padrão da Vite são para a sua API de Node.js. Para ajustar o ambiente de código do lado do cliente numa aplicação de Vite, adicionamos um ficheiro de declaração d.ts:

/// <reference types="vite/client" />

Alternativamente, podemos adicionar vite/client à compilerOptions.types dentro do nosso tsconfig.json:

tsconfig.json

{
  "compilerOptions": {
    "types": ["vite/client"]
  }
}

Isto fornecerá os seguintes ajustes de tipo:

• Importações de recurso (por exemplo, importação dum ficheiro .svg)
• Tipos para as variáveis de ambiente injetadas pela Vite sobre a import.meta.env
• Tipos para a API de Substituição de Módulo Instantânea sobre a import.meta.hot

DICA

Para sobrepor a tipificação padrão, adicionamos um ficheiro de declaração de tipo que contém as nossas tipificações. Então, adicionamos a referência de tipo antes de vite/client.

Por exemplo, para fazer a importação padrão dum componente *.svg de React:

• vite-env-override.d.ts (o ficheiro que contém as nossas tipificações):

 declare module '*.svg' {
   const content: React.FC<React.SVGProps<SVGElement>>
   export default content
 }

• O ficheiro contendo a referência para vite/client:

  /// <reference types="./vite-env-override.d.ts" />
  /// <reference types="vite/client" />

HTML

Os ficheiros de marcação de hipertexto .html estão na frente e no centro de um projeto de Vite, servindo como pontos de entrada para a nossa aplicação, tornando simples a criação de aplicações de página única e de várias páginas.

Quaisquer ficheiros de marcação de hipertexto na raiz do nosso projeto pode ser diretamente acessado por seu respetivo caminho de diretório:

• <root>/index.html -> http://localhost:5173/
• <root>/about.html -> http://localhost:5173/about.html
• <root>/blog/index.html -> http://localhost:5173/blog/index.html

Os elementos da linguagem de marcação de hipertexto tais como os marcadores <script type="module"> e <link href> são processados por predefinição, o que permite utilizar as funcionalidades da Vite nos ficheiros hiperligados. Os elementos gerais de recursos, tais como <img src>, <video src> e <source src>, também são rebaseados para garantir que são otimizados e hiperligados ao caminho correto:

<!doctype html>
<html>
  <head>
    <link rel="icon" href="/favicon.ico" />
    <link rel="stylesheet" href="/src/styles.css" />
  </head>
  <body>
    <div id="app"></div>
    <img src="/src/images/logo.svg" alt="logo" />
    <script type="module" src="/src/main.js"></script>
  </body>
</html>

Para optar por não processar a marcação de hipertexto em determinados elementos, podemos adicionar o atributo vite-ignore ao elemento, o que pode ser útil ao referenciar os recursos externos ou rede de entrega de conteúdo.

Vue

A Vite fornece suporte de Vue de primeira classe:

• Suporte de Componente de Ficheiro Único de Vue 3 através de @vitejs/plugin-vue
• Suporte de Extensão de Sintaxe de JavaScript de Vue 3 através de @vitejs/plugin-vue-jsx
• Suporte de Componente de Ficheiro Único de Vue 2.7 através de @vitejs/plugin-vue2
• Suporte de Extensão de Sintaxe de JavaScript de Vue 2.7 através de @vitejs/plugin-vue2-jsx

JSX

Os ficheiros .jsx e .tsx também são suportados de imediato. A tradução de código de JSX também é manipulada através da esbuild.

Os utilizadores da Vue devem usar a extensão @vitejs/plugin-vue-jsx oficial, a qual fornece funcionalidades especificas incluindo a substituição de módulo instantânea, resolução de componente global, diretivas e ranhuras.

Se estivermos usando JSX sem a React ou Vue, jsxFactory e jsxFragment personalizados podem ser configurados usando a opção esbuild. Por exemplo, para Preact:

vite.config.js

import { defineConfig } from 'vite'

export default defineConfig({
  esbuild: {
    jsxFactory: 'h',
    jsxFragment: 'Fragment',
  },
})

Mais detalhes na documentação da esbuild.

Nós podemos injetar os auxiliares de JSX usando jsxInject (que é uma opção apenas de Vite) para evitar as importações manuais:

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 Refundação 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 também são respeitados para @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 refundados para garantir a correção.

Os pseudónimos @import e a refundação de URL também são 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 por postcss-load-config, por exemplo, postcss.config.js), será automaticamente aplicado a todas as CSS importadas.

Nota que a minimização de CSS será executada depois da PostCSS e usará a opção build.cssTarget.

Módulos de CSS

Qualquer ficheiro de CSS terminando com .module.css é considerado um ficheiro dos módulos de CSS. A importação de tal ficheiro retornará o objeto do módulo correspondente:

example.module.css

.red {
  color: red;
}

import classes from './example.module.css'
document.getElementById('foo').className = classes.red

O comportamento dos módulos de CSS pode ser configurado através da opção css.modules.

Se css.modules.localsConvention for definido para ativar locais de camelCase (por exemplo, localsConvention: 'camelCaseOnly'), também podemos usar as importações nomeadas:

// .apply-color -> applyColor
import { applyColor } from './example.module.css'
document.getElementById('foo').className = applyColor

Pré-processadores de CSS

Uma vez que a Vite dirige-se apenas aos navegadores modernos, é recomendado usar as variáveis de CSS nativa com as extensões de PostCSS que implementam os rascunhos do Grupo de Trabalho da CSS (por exemplo, postcss-nesting) e escrever CSS simples e em conformidade com os futuros padrões.

Com isto dito, a Vite fornece suporte embutido para os ficheiros .scss, .sass, .less, .styl e .stylus. Não existe necessidade de instalar extensões específicas de Vite para estes, mas o próprio pré-processador correspondente deve estar instalado:

# .scss e .sass
npm add -D sass-embedded # ou sass

# .less
npm add -D less

# .styl e .stylus
npm add -D stylus

Se estivermos usando os componentes de ficheiro único da Vue, isto também ativa automaticamente <style lang="sass"> e outros.

A Vite melhora a resolução de @import para Sass e Less para que os pseudónimos da Vite também sejam respeitados. Além disto, as referências da url() relativa dentro dos ficheiros de Sass ou Less importados que estão em diretórios diferentes a partir do ficheiro de raiz também são rebaseados automaticamente para garantir a correção.

O pseudónimo de @import e o rebaseamento da URL não são suportados para a Stylus por causa das restrições da sua API.

Nós também podemos usar os módulos de CSS combinados com os pré-processadores anexando .module à extensão do ficheiro, por exemplo, style.module.scss.

Desativando a Injeção de CSS na Página

A injeção automática dos conteúdos da CSS pode ser desligada através do parâmetro de consulta ?inline. Neste caso, a sequência de caracteres da CSS processada é retornada como exportação padrão do modulo como de costume, mas os estilos não são injetados na página:

import styles from './foo.css' // será injetada na página
import otherStyles from './bar.css?inline' // não será injetada

NOTA

As importações padrão e nomeadas de ficheiros de CSS (por exemplo, import style from './foo.css') foram removidas desde a Vite 5. Use a consulta ?inline.

CSS Relâmpago

Desde a versão 4.4 da Vite, existe suporte experimental para a CSS Relâmpago. Nós podemos optar por testa opção adicionando css.transformer: 'lightningcss' ao nosso ficheiro de configuração e instalar a dependência opcional lightningcss:

npm add -D lightningcss

Se for ativada, os ficheiros de CSS serão processados pela CSS Relâmpago no lugar da PostCSS. Para configurá-la, podemos passar as opções da CSS Relâmpago à opção de configuração css.lightningcss.

Para configurar os Módulos de CSS, usaremos a css.lightningcss.cssModules no lugar da css.modules (que configura a maneira que a PostCSS manipula os módulos de CSS).

Por padrão, a Vite usa a esbuild para minimizar a CSS. A CSS Relâmpago também pode ser usada como minimizadora de CSS com a build.cssMinify: 'lightningcss'.

NOTA

Os pré-processadores de CSS não são suportados quando usamos a CSS relâmpago.

Recursos Estáticos

A importação dum recurso estático retornará a URL pública resolvida quando esta for servida:

import imgUrl from './img.png'
document.getElementById('hero-img').src = imgUrl

As consultas especiais podem modificar como os recursos são carregados:

// Carregar explicitamente os recursos como
// endereço de localização de recurso.
import assetAsURL from './asset.js?url'

// Carregar os recursos como sequências de caracteres
import assetAsString from './shader.glsl?raw'

// Carregar os Operadores da Web
import Worker from './worker.js?worker'

// Operadores da Web embutidos como sequências
// de caracteres de base64 no momento da construção
import InlineWorker from './worker.js?worker&inline'

Mais detalhes na Manipulação de Recurso Estático.

JSON

Os ficheiros de JSON podem ser importados diretamente - importações nomeadas também são suportadas:

// importar o objeto inteiro
import json from './example.json'
// importar um campo de raiz como exportação nomeada -
// ajuda com agitação da árvore!
import { field } from './example.json'

Importação de Globo

A Vite suporta a importação de vários módulos a partir do sistema de ficheiro através da função especial import.meta.glob:

const modules = import.meta.glob('./dir/*.js')

O código acima 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'),
}

Nós podemos então iterar sobre as chaves do objeto modules para acessar os módulos correspondentes:

for (const path in modules) {
  modules[path]().then((mod) => {
    console.log(path, mod)
  })
}

Os ficheiros correspondidos são por padrão carregados preguiçosamente através da importação dinâmica e serão divididos em pedaços separados durante a construção. Se preferirmos importar todos os módulos diretamente (por exemplo, dependendo dos efeitos colaterais nestes módulos para serem aplicados primeiro), podemos passar { eager: true } como segundo argumento:

const modules = import.meta.glob('./dir/*.js', { eager: true })

O código acima 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,
}

Padrões Múltiplos

O primeiro argumento pode ser um vetor de globos, por exemplo:

const modules = import.meta.glob(['./dir/*.js', './another/*.js'])

Padrões Negativos

Os padrões de globo negativo também são suportados (prefixados por !). Para ignorar alguns ficheiros a partir do resultado, podemos adicionar padrões de globo de exclusão ao primeiro argumento:

const modules = import.meta.glob(['./dir/*.js', '!**/bar.js'])

// código produzido pela vite
const modules = {
  './dir/foo.js': () => import('./dir/foo.js'),
}

Importações Nomeadas

É possível importar apenas as partes dos módulos com as opções de import:

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),
}

Quando combinada com eager é possível até mesmo ter a agitação da árvore ativada para estes módulos:

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,
}

Definimos import como default para importarmos a exportação padrão:

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,
}

Consultas Personalizadas

Nós também podemos usar a opção query para fornecer consultas personalizadas às importações, por exemplo, importar recursos como uma sequência de caracteres ou como uma URL:

const moduleStrings = import.meta.glob('./dir/*.svg', {
  query: '?raw',
  import: 'default',
})
const moduleUrls = import.meta.glob('./dir/*.svg', {
  query: '?url',
  import: 'default',
})

// código produzido pela 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']),
}

Nós também podemos fornecer consultas personalizadas para outras extensões consumirem:

const modules = import.meta.glob('./dir/*.js', {
  query: { foo: 'bar', bar: true },
})

Advertências sobre a Importação de Globos

Nota que:

• Isto é uma funcionalidade exclusiva da Vite e não é um padrão da Web ou ECMAScript.
• Os padrões de globos são tratados como especificadores de importação: estes devem ser relativos (começam com /) ou absolutos (começam com /, resolvidos em relação à raiz do projeto) ou um caminho de pseudónimo (consultar a opção resolve.alias).
• A correspondência do globo é feita através da tinyglobby.
• Nós também devemos estar cientes de que todos os argumentos na import.meta.glob devem ser passados como literais. Nós NÃO podemos usar variáveis ou expressões nelas.

Importação Dinâmica

Semelhante à importação de globo, a Vite também suporta a importação dinâmica com variáveis:

const module = await import(`./dir/${file}.js`)

Nota que as variáveis apenas representa nomes de ficheiros a um nível de profundidade. Se file for 'foo/bar', a importação falharia. Para uso mais avançado, podemos usar a importação de globo.

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()
})

A função de inicialização também pode receber um importObject que é passado para WebAssembly.instantiate como seu segundo argumento:

import init from './example.wasm?init'

init({
  imports: {
    someFunc: () => {
      /* ... */
    },
  },
}).then(() => {
  /* ... */
})

Na construção de produção, os ficheiros .wasm mais pequenos do que o assetInlineLimit serão embutidos como sequências de caracteres de base64. De outro modo, serão tratados como recurso estático e requisitados sob demanda.

NOTA

Proposta de Integração do Módulo de ECMAScript para a WebAssembly não é atualmente suportada. Use vite-plugin-wasm ou outras extensões da comunidade para lidar com isto.

Acessando o Módulo de WebAssembly

Se precisarmos de acesso ao objeto Module, por exemplo, para o instanciar várias vezes, usamos uma importação explícita de URL para resolver o recurso, e depois executamos a instanciação:

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 do lado do servidor, a fetch() acontecendo como parte da importação ?init, pode falhar com TypeError: Invalid URL. Consultar a questão Suportar wasm na Interpretação do Lado do Servidor.

Eis 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()

Operários da Web

Importações com Construtores

Um programa de operário da Web pode ser importado usando new Worker() e new SharedWorker(). Comparado aos sufixos do operário, esta sintaxe aproxima-se mais dos padrões e é a maneira recomendada para criar os operários:

const worker = new Worker(new URL('./worker.js', import.meta.url))

O construtor do operário também aceita opções, que podem ser usadas para criar operários de "módulo":

const worker = new Worker(new URL('./worker.js', import.meta.url), {
  type: 'module',
})

A deteção do operário apenas funcionará se o construtor new URL() for usado diretamente dentro da declaração new Worker(). Adicionalmente, todos os parâmetros de opções devem ser valores estáticos (isto é, literais de sequência de caracteres).

Importações com Sufixos de Consulta

Um programa de operário da Web pode ser importado diretamente adicionando ?worker ou ?sharedworker à requisição da importação. A exportação padrão será um construtor personalizado de operário:

import MyWorker from './worker?worker'

const worker = new MyWorker()

O programa do operário também pode usar declarações de import no lugar da importScripts(). Nota: durante o desenvolvimento isto depende do suporte nativo do navegador, mas para a construção de produção é compilado ao longe.

Por padrão, o programa do operário será emitido como um pedaço separado na construção de produção. Se desejamos embutir o operário como sequências de caracteres de base64, adicionamos a consulta inline:

import MyWorker from './worker?worker&inline'

Se desejamos recuperar o operário como uma URL, adicionamos a consulta url:

import MyWorker from './worker?worker&url'

Consultar as Opções do Operário por detalhes sobre a configuração do empacotamento de todos os operários.

Política de Segurança de Conteúdo (CSP)

Para implantar a política de segurança de conteúdo, certas diretivas ou configurações devem ser definidas por causa dos componentes internos da Vite.

'nonce-{RANDOM}'

Quando html.cspNonce é definida, a Vite adiciona um atributo de código de acesso com o valor especificado a quaisquer marcadores <script> e <style>, bem como os marcadores <link> para folhas de estilo e pré-carregamento de módulo. Adicionalmente, quando esta opção é definida, a Vite injetará um marcador meta (<meta property="csp-nonce" nonce="PLACEHOLDER" />).

O valor de código de acesso dum marcador de meta como property="csp-nonce" será usado pela Vita sempre que necessário, tanto durante o desenvolvimento quanto após a construção.

AVISO

Precisamos de garantir que substituímos o marcador de posição por um valor único para cada requisição. Isto é importante para evitar o contorno da política dum recurso, o que pode ser feito facilmente.

data:

Por padrão, durante a construção, a Vite incorpora pequenos recursos como identificadores uniformes de recurso de dados. É necessário permitir data: para diretivas relacionadas (por exemplo, img-src, font-src), ou, desativá-la definindo build.assetsInlineLimit: 0.

AVISO

Não devemos permitir data: para script-src. Isto permitirá a injeção de programas arbitrários.

Otimizações da Construção

As funcionalidades listadas abaixo são aplicadas automaticamente como parte do processo de construção e não existe necessidade para configuração explícita a menos que queiramos desativá-las.

Separação de Código de CSS

A Vite extrai automaticamente a CSS usada pelos módulos num pedaço assíncrono e gera um ficheiro separado para esta. O ficheiro da CSS é carregado automaticamente através dum marcador <link> quando o pedaço assíncrono associado for carregado, e o pedaço assíncrono tiver a garantia de ser apenas avaliado depois da CSS for carregada para evitar a Intermitência do Conteúdo Não Estilizado.

Se preferirmos ter todas as CSS extraídas num único ficheiro, podemos desativar a separação do código de CSS definindo a 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 diretas no HTML construído.

Otimização do Carregamento do Pedaço Assíncrono

Nas aplicações do mundo real, a Rollup muitas vezes gera os pedaços "comuns" - o código que é partilhado entre dois ou mais outros pedaços. Combinado com as importações dinâmicas, é muito comum ter o seguinte cenário:

Nos cenários não otimizados, quando o pedaço assíncrono A for importado, o navegador precisará requisitar e analisar sintaticamente a A antes de poder compreender que também precisa do pedaço comum C. Isto resulta numa viagem adicional de ida e volta na rede:

Entry ---> A ---> C

A Vite reescreve automaticamente as chamadas de importação dinâmica da separação de código com uma etapa de pré-carregamento para que quando A for requisitado, C seja requisitado em paralelo:

Entry ---> (A + C)

É possível para C ter importações adicionais, que resultarão em mais viagens de ida e volta no cenário não otimizado. A otimização da Vite rastreará todas as importações diretas para eliminar completamente as viagens de ida e volta independentemente da profundidade da importação.