Когда наш браузер не поддерживает модуль ES, мы будем извлекать, обрабатывать и подключать наш исходный код с помощью таких инструментов, как Webpack, Rollup, Parcel и т. д. Но когда наш проект становится все более и более сложным, количество модулей увеличивается Чем больше времени мы запускаем Dev Server, тем больше времени требуется для запуска Dev Server.Когда мы редактируем код, сохраняем его, даже если есть функция HRM, это может занять несколько секунд, чтобы отразиться на странице. Такой опыт разработки очень плохой, и Vite должен решить проблему такого опыта разработки. В целом Vite имеет следующие преимущества:
- Удалите шаг упаковки, быстрый холодный запуск
- Своевременное горячее обновление модулей, которое не будет тормозить горячее обновление по мере увеличения количества модулей
- Настоящая компиляция по запросу
Bundle vs Bundleless
Чтобы научиться понимать Vite, сначала поговорим о Bundle и Bundleless, которые представляют собой два разных метода разработки. В прошлом мы обычно использовали Webpack, инструмент для упаковки и построения, для упаковки и сборки нашего кода. прошлое? :
- HTTP/1.1 Каждый браузер имеет ограничение на количество одновременных подключений
- Браузер не поддерживает модульную систему (например, пакеты CommonJS нельзя запускать непосредственно в браузере)
- Зависимости кода и управление заказами
Зачем начинать пытаться не упаковывать
- Более длительное время ожидания запуска и горячих обновлений по мере роста проектов
- Мультиплексирование HTTP/2.0
- Основные браузеры поддерживают ESM один за другим
- Нативно решает проблему зависимости кода и повторного использования
- Все больше и больше пакетов npm включают ESM (хотя многие зависимости пакетов не поддерживаются)
| Пакет (веб-пакет) | Bundleless(Vite/Snowpack) | |
|---|---|---|
| Время начала | длинный, полный комплексный проект | Коротко, запускайте сервер только для загрузки по запросу |
| время сборки | растет линейно с объемом проекта | Сложность времени строительства O(1) |
| Загрузка производительности | Загрузите соответствующий пакет после упаковки | Запросы сопоставляются с локальными файлами |
| возможность кэширования | Использование кеша является общим, на него влияет режим разделения | Использование кеша близко к идеальному |
| обновление файла | переупаковывать | Повторно запросить один файл |
| Опыт отладки | Часто SourceMap требуется для отладки | Не сильно зависит от SourceMap, однофайловая отладка |
| экология | превосходно | В настоящее время он незрелый, но быстро развивается |
- Bundle vs Bundleless
- Bundle Refresh
- Bundleless Refresh
Вите принцип
Vite разделен на режим разработки и режим производства.
Режим разработки:, Vite предоставляет сервер разработки, а затем объединяет собственныйESM, когда в коде появляется импорт, отправьте запрос ресурса, сервер разработки Vite перехватит запрос и завершит перезапись модуля (например, синтаксический анализ и компиляцию одного файла и т. д.) и обработку запроса на сервере в соответствии с различными типами файлов, чтобы добиться реальной компиляции по требованию, а затем вернуться в браузер. Запрошенные ресурсы компилируются и возвращаются по запросу на стороне сервера, полностью игнорируя концепцию упаковки, и нет необходимости генерировать большой пакет. Сервер готов к использованию, поэтому первоначальный запуск в среде разработки происходит очень быстро. И скорость горячего обновления не будет замедляться по мере увеличения количества модулей, ведь после смены кода не будет процесса комплектации.
Вся логика Vite Server в основном зависит от реализации промежуточного программного обеспечения. Это промежуточное ПО после перехвата запроса выполняет следующее:
-
Обработка синтаксиса ESM, например преобразование путей импорта сторонних зависимостей в бизнес-коде в пути зависимостей, распознаваемые браузером;
-
Своевременная компиляция .ts, .vue и других файлов;
-
Скомпилируйте модули Sass/Less, которые необходимо предварительно скомпилировать;
-
Установите сокетное соединение с браузером для реализации HMR.
Режим производства:Используйте Rollup для создания исходного кода.
Vite делит код, который необходимо обработать, на две категории
сторонние зависимости: Большая часть кода этого типа представляет собой чистый JavaScript и меняется не очень часто. Vite будет обрабатывать эту часть кода с помощью метода pre-bundle.Что касается того, зачем нужен pre-bundle, об этом будет сказано позже. Vite2 использует esbulid для сборки этой части кода, esbuild основан на go, скорость обработки будет в 10-100 раз быстрее, чем у сборщика, написанного на JavaScript, что является одной из причин, почему Vite очень быстр на этапе разработки.
Бизнес-код: Обычно эта часть кода не является чистым JavaScript (например: JSX, Vue и т.д.), она часто модифицируется, и ее не нужно загружать сразу всю (можно сделать раздельную загрузку кода согласно роутингу)
Поскольку Vite использует собственный ESM, самому Vite нужно только скомпилировать код по запросу и запустить статический сервер. Эти модули компилируются и динамически загружаются на текущую страницу только тогда, когда браузер их запрашивает.
характерная черта
- NPM Dependency Resolving
Родной ESM не поддерживаетbare module imports, другими словами, собственный ESM поддерживает ссылки на ресурсы только через относительный или абсолютный путь и не поддерживает ссылки на ресурсы через имя пакета.
import React from 'react'
Uncaught TypeError: Failed to resolve module specifier "test2.js". Relative references must start with either "/", "./", or "../".
Когда мы раньше использовали Webpack для создания проектов, мы использовали этот метод импорта для импорта стороннего зависимого пакета, который мы установили. Фактически, Webpack помог нам сделать такой уровень преобразования. Аналогично, если вы хотите использовать ESM в ESM To ввести пакет таким образом, вы должны сделать такой слой преобразования пути.
- Dependency pre-bundling
На этапе разработки Vite обрабатывает весь код как собственный ESM, поэтому Vite должен преобразовать зависимости CommonJS или UMD в собственный ESM. Меньше модулей (уменьшает количество запросов). Vite преобразует зависимости ESM, содержащие множество внутренних модулей, в один модуль для повышения производительности последующей загрузки страницы. Предварительную упаковку нужно выполнять только при изменении зависимостей, но в проектах с большим количеством зависимостей каждое выполнение может занимать много времени. Раньше Vite использовал Rollup для выполнения этого процесса, в версии 2.0 мы перешли на esbuild, что ускорило процесс в десятки раз. В то же время Vite помогает нам настроить http-кэш для этих сторонних зависимых пакетов, чтобы при загрузке одного и того же ресурса мы могли напрямую читать кеш.
- Hot Module Replacement
- TypeScript
- Vue
- JSX
- CSS
- При импорте файла .css его содержимое будет внедрено на страницу с помощью разметки с поддержкой HMR.
- Усовершенствованный синтаксический анализ путей: пути @import и url() в CSS разрешаются с помощью синтаксического анализатора путей Vite, который поддерживает зависимости псевдонимов и npm.
Автоматическая перезапись URL-адресов: все пути url() автоматически перезаписываются, чтобы убедиться, что они указывают на правильные пути к файлам как при разработке, так и при сборке.
- Разделение кода CSS: при асинхронной загрузке модуля Vite автоматически извлечет CSS из модуля в отдельный файл, а когда модуль будет загружен, он будет загружен через тег стиля.
- css модуль поддержки
- CSS Pre-processors
- Static Assets
- JSON
- Web Assembly
- Web Workers
- Dynamic Import Polyfill
- Async Chunk Loading Optimization
Без оптимизации, когда мы загружаем асинхронный модуль, только после запроса и анализа текущего модуля мы обнаружим, что модуль также импортирует другие модули, а затем отправляет сетевые запросы, что требует дополнительных сетевых обходов, но Vite Код можно разобрать на знать, от каких непосредственно зависимых модулей зависит текущий асинхронный модуль, чтобы сетевые запросы можно было отправлять параллельно.
До оптимизации
Entry ---> A ---> C
Оптимизировано
Entry ---> (A + C)
Caching
кэш файловой системыVite будет хранить предварительные зависимости в node_modules/.vite. Предварительный пакет будет повторно предварительно объединен для обновления кеша только в случае возникновения следующих условий.
- The dependencies list in your package.json
- Package manager lockfiles, e.g. package-lock.json, yarn.lock, or pnpm-lock.yaml.
- Relevant fields in your vite.config.js, if present.
кеш браузераVite Dev Server настроит сильный кеш HTTP для этих сторонних зависимостей, чтобы повысить производительность.Только когда эти зависимости изменятся, он обновит идентификатор запроса, чтобы сделать предыдущий кеш недействительным.
Automatic Dependency Discovery
Если зависимость не найдена в кеше, Vite автоматически найдет ее в node_modules и извлечет в кеш. Vite будет хранить предварительные зависимости в node_modules/.vite.
Почему вам все еще нужны пакеты в производственных средах?
Хотя встроенный ESM теперь широко поддерживается, использование разделенного ESM в рабочей среде по-прежнему неэффективно, даже с HTTP2, из-за большого количества сетевых запросов, вызываемых вложенным импортом. Для наилучшей производительности загрузки в продакшене лучше всего связать код один раз (в сочетании с такими методами, как встряхивание дерева, отложенная загрузка и обычное разделение фрагментов).
Почему бы не использовать ESbuild в продакшене
esbuild очень быстр и уже является очень мощным компоновщиком, но некоторые важные функции, необходимые для связывания приложений, все еще находятся в разработке, особенно разделение кода и обработка CSS. В настоящее время Rollup является более зрелым и гибким в этих областях. Тем не менее, мы не исключаем возможности использования esbuild в производственных сборках, когда esbuild стабилизирует эти функции в будущем.
Сравнение со Снежным пакетом
Snowpack также является локальным сервером разработки, основанным на собственном ESM, с некоторыми сходствами, но также и с некоторыми отличиями.
Production Build
Файлы сборки Snowpack по умолчанию не связаны, он преобразует каждый файл в отдельный модуль сборки, а затем передает эти модули различным «оптимизаторам» для выполнения фактической операции сборки. Преимущество этого в том, что вы можете использовать разные конечные упаковщики (например, webpack, rollup, esbuild) для удовлетворения конкретных потребностей.
Поскольку Vite объединяет шаги сборки, Vite поддерживает больше функций (которые еще не поддерживаются в Snowpack).
-
Официальныйlegacy mode pluginПлагин, который может генерировать двойные пакеты, поддерживающие современные/старые браузеры, и автоматически доставлять правильный пакет в зависимости от браузера.
Faster Dependency Pre-BundlingТак как на этапе разработки Vite использует esbuild для предварительной сборки, что намного быстрее, чем Rollup
Monorepo Support CSS Pre-Processor Support First Class Vue Support
Поддержка браузера
- В среде разработки требуется браузер, изначально поддерживающий ESM.
- В производственной среде по умолчанию также требуется браузер, поддерживающий собственный ESM, но доступ к нему можно получить через@vitejs/plugin-legacyдля создания пакетов, поддерживающих старые браузеры
В проекте, созданном Webpack, наш входной файл обычно представляет собой js, а index.html используется только как шаблон, а в проекте, созданном Vite, index.html используется в качестве входного файла.
Справочная статья
Углубленный принцип vite: как реализован последний шедевр Юды?
Vite полагается на предварительную компиляцию, сокращая время холодного запуска в несколько раз
Расскажите о ESM, Bundle, Bundleless, Vite, Snowpack.
Глядя на интерфейсные сборки от Bundleless