Зависимость Предварительно Связана

Когда вы запускаете vite в первый раз, выложите предварительные зависимости своего проекта, прежде чем загружать ваш сайт локально. Это делается автоматически и прозрачно по умолчанию.

Почему

Это Vite, выполняющий то, что мы называем «предварительной сгруппировкой зависимости». Этот процесс служит двум целям:

1. CommonJS и UMD Совместимость: во время разработки Dev Veite обслуживает весь код в качестве нативного ESM. Следовательно, VITE должен сначала преобразовать зависимости, которые отправляются как CommonJS или UMD в ESM.

   При преобразовании зависимостей CommonJS VITE выполняет интеллектуальный импорт, так что названный импорт в CommonJS будет работать, как и ожидалось, даже если экспорт назначается динамически (например, React):

   // Работает, как и ожидалось
   import React, { useState } from 'react'

2. Производительность: VITE преобразует зависимости ESM со многими внутренними модулями в один модуль для улучшения последующей производительности загрузки страницы.

   Некоторые пакеты отправляют свои модули ES, создают столько же отдельных файлов, импортирующих друг друга. Например, lodash-es имеет более 600 внутренних модулей ! Когда мы делаем import { debounce } from 'lodash-es' , браузер выпускает 600+ HTTP -запросов одновременно! Несмотря на то, что на сервере нет проблем с их обращением, большое количество запросов создает заторы сети на стороне браузера, что приводит к тому, что страница будет заметно медленнее.

   Предварительно связанной lodash-es в один модуль, нам теперь нужен только один HTTP-запрос!

NOTE

Зависимость предварительная сжигания применяется только в режиме разработки и использует esbuild для преобразования зависимостей в ESM. В производственных сборках @rollup/plugin-commonjs используется вместо этого.

Автоматическое Обнаружение Зависимостей

Если существующий кэш не найден, Vite будет ползти на исходном коде и автоматически обнаруживает импорт зависимости (то есть «голый импорт», который ожидает разрешить от node_modules ) и использовать эти обнаруженные импорты в качестве точек входа для предварительного сбора. Предварительное объединение выполняется с esbuild так что это обычно очень быстро.

После того, как сервер уже начался, если встречается новый импорт зависимости, который еще не в кеше, Vite повторно запустит процесс комплекса DEP и при необходимости перезагрузить страницу.

Monorepos И Связанные Зависимости

В настройке Monorepo зависимостью может быть связанным пакетом из того же репо. VITE автоматически обнаруживает зависимости, которые не разрешаются от node_modules и рассматривают связанный DEP как исходный код. Он не будет пытаться объединить связанный DEP, и вместо этого будет анализировать связанный список зависимостей DEP.

Тем не менее, это требует, чтобы связанный DEP был экспортирован как ESM. Если нет, вы можете добавить зависимость до optimizeDeps.include и build.commonjsOptions.include в конфигурации.

vite.config.js

import { defineConfig } from 'vite'
// ---резать---
export default defineConfig({
  optimizeDeps: {
    include: ['linked-dep'],
  },
  build: {
    commonjsOptions: {
      include: [/linked-dep/, /node_modules/],
    },
  },
})

При внесении изменений в связанный DEP перезапустите сервер Dev с опцией командной строки --force для вступления в силу.

Настройка поведения

Эвристика обнаружения зависимостей по умолчанию не всегда может быть желательной. В тех случаях, когда вы хотите явно включить/исключить зависимости из списка, используйте параметры конфигурации optimizeDeps .

Типичный вариант использования для optimizeDeps.include или optimizeDeps.exclude - это когда у вас есть импорт, который не доступен непосредственно в исходном коде. Например, возможно, импорт создается в результате преобразования плагина. Это означает, что VITE не сможет обнаружить импорт на начальном сканировании - он может обнаружить его только после того, как файл запросил браузер и преобразован. Это приведет к тому, что сервер немедленно переоборудован после запуска сервера.

Обе include и exclude могут быть использованы для борьбы с этим. Если зависимость велика (со многими внутренними модулями) или является обычным делом, то вы должны включить ее; Если зависимость небольшая и уже является действительной ESM, вы можете исключить ее и позволить браузеру загрузить ее напрямую.

Вы также можете настроить Esbuild также с помощью опции optimizeDeps.esbuildOptions . Например, добавление плагина Esbuild для обработки специальных файлов в зависимости или изменения сборки target .

Кэширование

Кэш Файловой Системы

Проверка кэширует предварительно связанные зависимости в node_modules/.vite . Он определяет, нужно ли ему повторно запустить этап предварительного сжигания на основе нескольких источников:

• Содержание блокировки диспетчера пакетов, например, package-lock.json , yarn.lock , pnpm-lock.yaml или bun.lockb .
• Патчи времени модификации папки.
• Соответствующие поля в вашем vite.config.js , если присутствуют.
• NODE_ENV

Предварительный шаг должен быть заполнен только тогда, когда одно из вышеперечисленных изменилось.

Если по какой-то причине вы хотите заставить VITE для повторного сбора DEPS, вы можете запустить сервер Dev с опцией командной строки --force или вручную удалить каталог node_modules/.vite кэша.

Кэш Браузера

Решенные запросы на зависимость сильно кэшируются с HTTP -заголовками max-age=31536000,immutable чтобы улучшить производительность перезагрузки страницы во время разработки. После кэширования эти запросы больше никогда не попадут на сервер Dev. Они автоматически не имеют права на добавленную версию запроса, если установлена другая версия (как отражено в вашем файле блокировки менеджера пакета). Если вы хотите отладить свои зависимости, внесите местные изменения, вы можете:

1. Временно отключить кэш через вкладку сети в браузере Devtools;
2. Перезапустите Vite Dev Server с флагом --force для повторного сбора DEPS;
3. Перезагрузить страницу.