{
  "index": 345,
  "slug": "editorial-2018-06-practice-webpack-entry",
  "title": "Webpack 4: две страницы, общие chunks и проверяемая сборка",
  "excerpt": "Две HTML-страницы могут тянуть один и тот же код дважды. Разбираем границу entry, настройку splitChunks и проверку итоговых ассетов в Webpack 4.",
  "contentHtml": "<p>Рассмотрим учебный сценарий после добавления страницы заказа. В сборке появились <code>catalog.js</code> и <code>checkout.js</code>, а jQuery и модуль форматирования цены попали в оба entry-бандла. При этом сама страница каталога не обязана загружать код заказа: общий модуль и соседний entry — разные проблемы. Если их смешать, первый запрос растёт, кеширование становится менее предсказуемым, а граница страниц теряется.</p>\n<p>Первое предположение — ошибка в импорте: кажется, что каталог случайно подтянул <code>checkout.js</code>. Проверка сгенерированного HTML показывает, что лишнего entry там нет. В <code>stats</code> повторяются именно общие зависимости. Значит, нужно разделить два вопроса: entry описывает точку запуска документа, а <code>optimization.splitChunks</code> может вынести модуль, который используется несколькими chunks. Общий модуль не становится общим только из-за имени папки <code>shared</code>.</p>\n<h2>Что именно считает Webpack</h2>\n<p>Entry — это точка, с которой Webpack начинает строить граф зависимостей. В многостраничном сайте у документа каталога есть свой entry, у документа заказа — свой. Два entry дают два графа импортов. Если оба графа доходят до <code>src/shared/money.js</code>, этот модуль является общей зависимостью, но способ его выдачи зависит от настроек оптимизации.</p>\n<p>Entry отвечает на вопрос «какой сценарий запускается». <code>splitChunks</code> отвечает на вопрос «какие модули можно вынести в отдельный chunk». <code>runtimeChunk</code> отвечает за служебный runtime Webpack, который связывает модули и chunks. Третий entry с именем <code>common</code> не заменяет оптимизацию: он сам становится ещё одной точкой запуска и может изменить поведение страницы.</p>\n<figure><img src='/assets/editorial/2018/webpack-entry-shared-chunks-2018.svg' alt='Две страницы Webpack 4 запускают разные entry и используют общие runtime, vendors и common chunks' /><figcaption>У каталога и заказа свои entry. Общие chunks подключаются к нужному документу, но соседний page-entry в его HTML не появляется.</figcaption></figure>\n<h2>Минимальный граф зависимостей</h2>\n<p>Ниже учебный пример. Он показывает механизм, но не обещает конкретные размеры файлов и не заменяет сборку проекта. Оба сценария статически используют jQuery и одну функцию. Код страницы остаётся раздельным.</p>\n<pre><code>// 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}</code></pre>\n<p>Если собрать этот граф без подходящего правила <code>splitChunks</code>, Webpack может оставить повторяющуюся зависимость в стартовых chunks. Это не означает, что каталог получил весь <code>checkout.js</code>: оба entry просто содержат код, который им нужен. Для проверки сохраните <code>stats.json</code> и найдите один и тот же модуль в обоих entry. Решение принимайте по фактическим ассетам и сетевым запросам, а не по названию исходной директории.</p>\n<h2>Конфигурация Webpack 4</h2>\n<p>В Webpack 4 оставьте в <code>entry</code> реальные точки запуска документов. Для общих библиотек используйте <code>splitChunks</code>. В учебном примере <code>minSize: 0</code> помогает увидеть даже маленький модуль. В рабочей сборке это условие может создать отдельный запрос ради нескольких строк, поэтому порог проверяют на размере и времени загрузки конкретного проекта.</p>\n<pre><code>// 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};</code></pre>\n<p>Группа <code>vendors</code> отбирает модули из <code>node_modules</code>, поэтому в примере в неё попадёт jQuery. Группа <code>common</code> ищет код, который достигается как минимум из двух chunks. Приоритет <code>-10</code> выше, чем <code>-20</code>, поэтому пересекающаяся зависимость сначала подходит под более приоритетную группу. Конкретный состав результата всё равно нужно проверить в stats.</p>\n<p><code>runtimeChunk: 'single'</code> создаёт один runtime-файл для всех сгенерированных chunks. В многостраничном сайте это помогает кешировать runtime, но каждый HTML-документ должен подключить этот файл не более одного раза. Если два entry намеренно запускаются на одной странице, нужно отдельно проверить их совместимость и число runtime: один runtime не исправляет ошибку в разметке.</p>\n<h2>Как страница подключает результат</h2>\n<p>Имена с <code>[contenthash]</code> меняются после содержательных изменений. HTML не должен навсегда содержать строки из примера: шаблонизатор или серверная сборка должны получить актуальную карту ассетов. Для обычного статического подключения ожидаемый порядок такой: runtime, общие chunks, затем код конкретной страницы. Фактический порядок проверяйте по карте ассетов и сгенерированному HTML.</p>\n<pre><code>&lt;!-- catalog.html: имена условные, порядок показан явно --&gt;\n&lt;script src='/assets/runtime.8ab1.js'&gt;&lt;/script&gt;\n&lt;script src='/assets/vendors.34cd.js'&gt;&lt;/script&gt;\n&lt;script src='/assets/common.91ef.js'&gt;&lt;/script&gt;\n&lt;script src='/assets/catalog.a2b3.js'&gt;&lt;/script&gt;</code></pre>\n<p>Страница каталога не должна подключать <code>checkout</code>, а страница заказа — <code>catalog</code>. Если общий chunk не появился, это не всегда ошибка: модуль мог быть слишком мал, использоваться только одним entry или не пройти условия cache group. Откройте HTML и Network, чтобы отличить лишний page-entry от допустимого дублирования или результата других оптимизаций.</p>\n<h2>Симптом → причина → проверка → действие</h2>\n<div class='table-scroll'><table><thead><tr><th scope='col'>Симптом</th><th scope='col'>Причина</th><th scope='col'>Проверка</th><th scope='col'>Действие</th></tr></thead><tbody><tr><td>В stats один модуль есть в обоих entry</td><td>Общая зависимость не попала в подходящую cache group</td><td>Сопоставить модуль, chunk и entry</td><td>Проверить <code>chunks</code>, <code>minChunks</code>, <code>minSize</code> и путь модуля</td></tr><tr><td>На странице заказа запускается каталог</td><td>HTML подключает соседний page-entry</td><td>Открыть список script-тегов и вкладку Network</td><td>Оставить runtime, нужные общие chunks и <code>checkout</code></td></tr><tr><td>После сборки не найден общий файл</td><td>Код мал или нужен только одному entry</td><td>Проверить число достижений модуля в stats</td><td>Не создавать chunk ради имени; сравнить стоимость запроса и дублирования</td></tr><tr><td>В консоли ошибка при старте</td><td>Неверный порядок или устаревший hash в HTML</td><td>Очистить кеш, проверить ответы Network и карту ассетов</td><td>Формировать HTML из актуальных имён и проверить порядок загрузки</td></tr><tr><td>Общий chunk стал слишком большим</td><td>В него попал код редкого сценария</td><td>Сопоставить состав chunk с первым экраном</td><td>Ослабить cache group или перенести поздний код в динамический <code>import()</code></td></tr></tbody></table></div>\n<h2>Порядок действий</h2>\n<ol><li>Перечислите HTML-документы и подтвердите, что каждый документ запускает отдельный сценарий.</li><li>Создайте по одному entry на документ. Не добавляйте в <code>entry</code> библиотеки только ради их общего имени.</li><li>Найдите повторяющийся импорт и сохраните stats до изменения конфигурации.</li><li>Настройте <code>splitChunks</code> и отдельно решите, нужен ли единый <code>runtimeChunk</code>.</li><li>Сделайте production-сборку и сравните список модулей, chunks и размеры ассетов до и после.</li><li>Проверьте HTML каждого документа. В нём должен быть собственный entry и только необходимые общие chunks.</li><li>Откройте обе страницы с очищенным кешем. Проверьте консоль, Network и отсутствие кода соседнего сценария.</li><li>Измените один общий модуль, повторите сборку и убедитесь, что изменились ожидаемые hash и chunks, а не случайный page-entry.</li></ol>\n<h2>Отрицательный путь и ограничения</h2>\n<p>Не всякий общий импорт нужно выносить. Маленький модуль может дешевле повторить, чем загружать новый файл. Большая библиотека может использоваться двумя entry, но быть нужна только после открытия модального окна. Тогда общий стартовый chunk ухудшит первую загрузку; для позднего кода рассмотрите динамический <code>import()</code> и проверьте его отдельным сценарием.</p>\n<p>Эта схема относится к Webpack 4. В ней нет API <code>dependOn</code> из Webpack 5, и настройки другой версии нельзя переносить без сверки документации. Webpack также не исправит ошибку, если один HTML намеренно подключает два page-entry: нужно отдельно проверить количество runtime, порядок запуска и побочные эффекты модулей.</p>\n<p>Учебный пример не доказывает выигрыш в production. На результат влияют размер модулей, HTTP-протокол, кеш, HTML, который формирует сервер, и порядок загрузки. Сравнивайте измеренные ассеты и запросы своего проекта; если выигрыш не подтверждается, верните конфигурацию к меньшему числу запросов.</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>Считайте работу готовой, когда для каждой страницы можно показать четыре доказательства: entry, который запускает сценарий; список общих chunks; отсутствие entry соседней страницы; успешный запуск с очищенным кешем. Эти сведения должны совпадать в конфигурации, сгенерированном HTML, stats и вкладке Network. Размер одного стартового файла сам по себе не является критерием. Если проверка снова показывает лишний <code>checkout</code> в каталоге, сначала исправьте HTML, а не добавляйте ещё одну cache group.</p>\n<h2>Проверяемые источники</h2><ul><li><a href='https://v4.webpack.js.org/concepts/entry-points/' target='_blank' rel='noopener noreferrer'>Webpack 4: Entry Points</a></li><li><a href='https://v4.webpack.js.org/guides/code-splitting/' target='_blank' rel='noopener noreferrer'>Webpack 4: Code Splitting</a></li><li><a href='https://v4.webpack.js.org/configuration/optimization/' target='_blank' rel='noopener noreferrer'>Webpack 4: optimization</a></li></ul>"
}