{ "index": 345, "slug": "editorial-2018-06-practice-webpack-entry", "title": "Webpack 4: две страницы, общие chunks и проверяемая сборка", "excerpt": "Две HTML-страницы могут тянуть один и тот же код дважды. Разбираем границу entry, настройку splitChunks и проверку итоговых ассетов в Webpack 4.", "contentHtml": "
После добавления страницы заказа production-сборка стала тяжелее. В каталоге появились catalog.js и checkout.js, а jQuery и модуль форматирования цены повторяются в обоих файлах. Пользователь каталога загружает код заказа, хотя не открывает заказ. Ошибка увеличивает первый запрос, усложняет кеширование и маскирует реальную границу страниц.
Причина проста: два entry запускают два графа зависимостей. Webpack видит общий импорт из каждого графа, но не обязан сам превратить его в отдельный файл. Нужны два решения: entry должны описывать реальные точки запуска, а optimization.splitChunks — выделять код, который достигается из нескольких chunks. Общий модуль не становится общим только из-за имени папки shared.
Entry — это начало выполнения конкретного сценария. В многостраничном сайте у документа каталога есть свой entry, у документа заказа — свой. Каждый entry строит граф импортов. Если оба графа доходят до src/shared/money.js, модуль присутствует в обоих графах. Дальше оптимизатор сравнивает размер, число использований и правила cache group.
Эти уровни нельзя смешивать. Entry отвечает на вопрос «какой сценарий стартует». splitChunks отвечает на вопрос «какие модули вынести в отдельный chunk». runtimeChunk отвечает за служебный runtime Webpack, который связывает модули и chunks. Третий entry с именем common не заменяет оптимизацию: он сам становится ещё одной точкой запуска.
catalog и checkout запускают свои сценарии, а общие chunks подключаются к обеим страницам.Ниже учебный пример. Он показывает механизм, но не обещает конкретные размеры файлов и не заменяет сборку проекта. Оба сценария используют jQuery и одну функцию. Код страницы остаётся раздельным.
\n// src/catalog.js\nimport $ from 'jquery';\nimport { formatPrice } from './shared/money';\n\n$('[data-price]').each(function () {\n this.textContent = formatPrice(this.dataset.price);\n});\n\n// src/checkout.js\nimport $ from 'jquery';\nimport { formatPrice } from './shared/money';\n\n$('[data-total]').text(formatPrice(window.checkoutTotal));\n\n// src/shared/money.js\nexport function formatPrice(value) {\n return Number(value).toFixed(2) + ' ₽';\n}\nЕсли собрать такой граф только с двумя entry, сборщик создаст стартовые chunks для каталога и заказа. Общий код может остаться внутри них. Это допустимый результат с точки зрения корректности: оба сценария получают нужный модуль. Но он может быть невыгоден для первой загрузки. Поэтому решение нужно принимать по списку ассетов и сетевому запросу, а не по названию исходной директории.
\nВ Webpack 4 оставьте в entry только реальные точки запуска. Для общих библиотек используйте splitChunks. В учебном примере minSize: 0 помогает увидеть даже маленький модуль. В рабочей сборке это условие может создать отдельный запрос ради нескольких строк. Порог нужно проверить на размере и времени загрузки конкретного проекта.
// webpack.config.js\nconst path = require('path');\n\nmodule.exports = {\n mode: 'production',\n entry: {\n catalog: './src/catalog.js',\n checkout: './src/checkout.js',\n },\n output: {\n path: path.resolve(__dirname, 'dist'),\n filename: '[name].[contenthash].js',\n },\n optimization: {\n runtimeChunk: 'single',\n splitChunks: {\n chunks: 'all',\n cacheGroups: {\n vendors: {\n test: /[\\/]node_modules[\\/]/,\n name: 'vendors',\n chunks: 'all',\n priority: -10,\n },\n common: {\n name: 'common',\n minChunks: 2,\n minSize: 0,\n chunks: 'all',\n priority: -20,\n reuseExistingChunk: true,\n },\n },\n },\n },\n};\nГруппа vendors отбирает модули из node_modules. Группа common ищет код, который достигается как минимум из двух chunks. Приоритеты разрешают пересечение правил. reuseExistingChunk: true позволяет повторно использовать уже созданный chunk, когда это возможно.
runtimeChunk: 'single' выносит runtime в отдельный общий файл. Он не выносит jQuery и не делает общий chunk из money.js. За это отвечает splitChunks. Если убрать runtime из проверки, можно ошибочно решить, что два похожих служебных фрагмента — это дублирование прикладного кода.
Имена с [contenthash] меняются после содержательных изменений. HTML не должен навсегда содержать строку из примера. Шаблонизатор, плагин или серверная сборка должны получить актуальную карту ассетов. Важно также сохранить порядок: runtime, общие chunks, затем код конкретной страницы.
<!-- catalog.html: имена условные, порядок показан явно -->\n<script src=\"/assets/runtime.8ab1.js\"></script>\n<script src=\"/assets/vendors.34cd.js\"></script>\n<script src=\"/assets/common.91ef.js\"></script>\n<script src=\"/assets/catalog.a2b3.js\"></script>\nСтраница каталога не должна подключать checkout. Страница заказа не должна подключать catalog. Если общий chunk не появился, это не всегда ошибка: модуль мог быть слишком мал, использоваться только одним entry или не пройти условия cache group. Проверяйте фактическую карту сборки.
| Симптом | Причина | Проверка | Действие |
|---|---|---|---|
| Оба entry заметно повторяют jQuery | Общий модуль не попал в подходящую cache group | Посмотреть stats и список модулей в chunks | Проверить chunks, minChunks, minSize и путь модуля |
| На странице заказа запускается каталог | HTML подключает соседний entry | Открыть вкладку Network и список script-тегов | Оставить в шаблоне только runtime, нужные общие chunks и checkout |
| После сборки не найден общий файл | Код мал или нужен только одному entry | Проверить число достижений модуля в stats | Не создавать chunk ради имени; сравнить стоимость запроса и дублирования |
| В консоли ошибка при старте | Неверный порядок или устаревший hash в HTML | Очистить кеш, проверить ответы Network и порядок загрузки | Формировать HTML из актуальной карты ассетов |
| Общий chunk стал слишком большим | В него попал код, который нужен только редкому сценарию | Сопоставить состав chunk с первым экраном | Ослабить cache group или перенести поздний код в динамический import() |
entry библиотеки только ради их общего имени.splitChunks и отдельно решите, нужен ли единый runtimeChunk.Не всякий общий импорт нужно выносить. Маленький модуль может дешевле повторить, чем загружать новый файл. Большая библиотека может использоваться двумя entry, но быть нужна только после открытия модального окна. В таком случае общий стартовый chunk ухудшит первую загрузку. Для позднего кода рассмотрите динамический import() и проверяйте его отдельным сценарием.
Эта схема относится к Webpack 4. В ней нет современного API dependOn, и нельзя переносить настройки из другой версии без сверки документации. Сборка также не исправит ошибку, если один HTML намеренно подключает два entry: нужно отдельно проверить количество runtime и порядок запуска.
Учебный пример не доказывает выигрыш в production. На него влияют размер модулей, HTTP-протокол, кеш, HTML, который формирует сервер, и порядок загрузки. Сравнивайте измеренные ассеты и запросы своего проекта.
\nСчитайте работу готовой, когда для каждой страницы можно показать четыре доказательства: entry, который запускает сценарий; список общих chunks; отсутствие entry соседней страницы; успешный запуск с очищенным кешем. Эти сведения должны совпадать в конфигурации, сгенерированном HTML, stats и вкладке Network. Размер одного стартового файла сам по себе не является критерием.
\n