1. Por que você precisa de vite

Criamos um arquivo index.html, introduzimos main.js nele e introduzimos counter.js em main.js

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, user-scalable=no, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0" />
  </head>
  <body>
    <script src="./main.js" type="module"></script>
  </body>
</html>

main.js

import { count } from"./counter.js"
console.log(' count: ',  count);

contador.js

export const count = 0;

Quando o abrimos em um navegador, o console normalmente exibe o conteúdo do console, o que não é problema.

Mas e se introduzirmos o pacote npm em counter.js usando um plug-in?

npm i lodash

import _ from "lodash"; 
console.log("lodash", _);
export const count = 0;

Neste momento, o navegador relatará um erro

Como os navegadores reconhecem apenas caminhos relativos ou caminhos absolutos, o modo de importação _ de "lodash" não pode ser reconhecido pelos navegadores.

Então, por que o navegador não nos ajuda por padrão quando importamos recursos com caminhos não absolutos e caminhos não relativos?

Os templates são interdependentes, se o navegador nos ajudar a identificar a importação, fará com que o navegador carregue um arquivo dependente muito grande, o que o tornará muito lento!

Neste momento, podemos usar o vite para nos ajudar a percebê-lo, está fora da caixa.

2. Apresente vite

npm i vite -D

Vamos adicionar o comando de atalho vite em package.json

 "scripts": {
    "dev": "vite"
  },

Em seguida, inicie o npm run dev na linha de comando, você pode ver que o projeto foi iniciado com sucesso

Abra a página da Web e você também verá que o código é executado normalmente ( execute code: console.log("lodash", _); ).

Funciona fora da caixa! !

3. Pré-carregamento do vite - contando com a pré-compilação

O Vite pode reconhecer referências de caminho não absolutas ou relativas porque executa a conclusão do caminho. Abra o console e podemos ver a resposta

l O caminho de carregamento do odash mudou para node_modules/.vite/deps/lodash.js?v=1484ebe8 . Pode-se descobrir que o vite pré-processa o loadsh e o coloca no diretório node_modules/.vite/deps .

Por que usar este método de carregamento?

Na verdade, foi Vite quem resolveu esse problema considerando outro problema!

Sabemos que alguns pacotes são exportados de acordo com a especificação commonjs , o que torna o navegador incapaz de reconhecer este formato de exportação. Para resolver esse problema, o vite possui dependências pré-construídas .

3.1 Confie na pré-construção

Primeiro, o vite encontrará as dependências necessárias no projeto e, em seguida, chamará esbuild (biblioteca para processar a sintaxe js) para converter outros códigos de especificação em especificações esmodule ; em seguida, coloque-os na pasta node_modules/.vite/deps ; Os vários módulos de a especificação do esmodule é unificada e integrada.

Essa ideia de design resolve três problemas:

Unifique os pacotes exportados por diferentes especificações na especificação esmodule
Você pode usar diretamente .vite/deps para processamento de caminhos, o que é conveniente para reescrever caminhos
Resolvido um problema de desempenho com transferências de vários pacotes de rede

3.1.1 Processamento de código pré-construído

Vamos instalar o lodash-es para ver como confiar no código pré-criado

npm i lodash-es -D

Introduzimos lodash-es em main.js e, em seguida, inserimos a parte do código-fonte lodash-es

import { count } from"./counter.js"
import lodashES from "lodash-es"
console.log('lodashES: ', lodashES);
console.log(' count: ',  count);

Pode-se ver que no arquivo de entrada principal lodash, muitas funções baseadas na especificação es são exportadas

Abra o console do navegador, descobriremos que o código aqui é pré-processado pelo vite e colocado no diretório /node_modules/.vite/deps

Podemos resumir o processamento feito por vite

Coloque os arquivos processados no diretório /node_modules/.vite/deps
Integração unificada de cada módulo da especificação esmodule (colocando as funções de exportação dispersas em um arquivo).

Vamos dar uma olhada no que acontecerá se os vários módulos da especificação do esmodule não forem integrados uniformemente.

Desative a pré-compilação da dependência

Criamos vite..config.js no diretório raiz do projeto e fechamos a pré-construção do projeto de lodash-es por meio da configuração.

import { defineConfig } from "vite";

export default defineConfig({
    optimizeDeps: {
        exclude: ["lodash-es"], // 将指定数组中的依赖不进行依赖预构建
    },
});

Neste ponto, abra o console do navegador e você pode ver claramente que o endereço de solicitação de lodash-es foi alterado para o endereço real.

Aparentemente, a pré-construção de lodash-es está desativada. No entanto, neste ponto, todas as dependências relacionadas ao es são carregadas.

Apenas um lodash-es faz com que o navegador solicite tantos arquivos! Esta é uma das razões pelas quais a especificação nativa do esmodule não ousa suportar node_modules.

3.2vite depende das vantagens da pré-construção

Através do exemplo acima, sabemos que não importa quantos exports e imports uma determinada biblioteca tenha após a pré-compilação da dependência, o vite irá integrá-los o máximo possível e, finalmente, gerar apenas um ou alguns módulos para nosso uso.

[Vite · 3] O uso básico do Vite e seu mecanismo de pré-carregamento dependente (muito detalhado para entender rapidamente)