Несколько точек входа как инструмент разделения

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

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

Базовая конфигурация нескольких entry

Классический способ определения нескольких точек входа заключается в использовании объекта в поле entry.

module.exports = {
  entry: {
    home: './src/home.js',
    admin: './src/admin.js',
    profile: './src/profile.js'
  },
  output: {
    filename: '[name].bundle.js',
    path: __dirname + '/dist'
  }
};

В этой конфигурации создаются три независимых бандла:

  • home.bundle.js
  • admin.bundle.js
  • profile.bundle.js

Ключи объекта entry становятся именами выходных файлов через шаблон [name].

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

Разделение по страницам приложения

Наиболее распространённый сценарий использования нескольких точек входа — многостраничные приложения. Каждая страница имеет собственный набор логики и минимально пересекается с другими.

entry: {
  landing: './src/pages/landing/index.js',
  dashboard: './src/pages/dashboard/index.js',
  settings: './src/pages/settings/index.js'
}

Такое разделение позволяет:

  • изолировать код страниц
  • уменьшить начальный объём загружаемого JavaScript
  • избежать загрузки неиспользуемой логики

Webpack в данном случае строит отдельные dependency graph для каждой страницы.

Природа изоляции графов зависимостей

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

Если два entry используют один и тот же модуль:

// home.js
import utils from './utils';

// admin.js
import utils from './utils';

то без дополнительной оптимизации модуль utils может попасть в оба бандла.

Это поведение приводит к необходимости использования механизмов извлечения общих зависимостей.

Проблема дублирования кода

При нескольких entry без оптимизации возникает повторение кода. Это особенно заметно в следующих случаях:

  • общие библиотеки (lodash, axios, date-fns)
  • UI-компоненты
  • утилитарные функции
  • системы инициализации

Дублирование приводит к:

  • увеличению общего размера сборки
  • повторной загрузке одинакового кода в браузере
  • ухудшению кеширования

Webpack решает эту проблему через optimization.splitChunks.

Выделение общего кода через splitChunks

При нескольких точках входа часто используется настройка:

module.exports = {
  entry: {
    home: './src/home.js',
    admin: './src/admin.js'
  },
  optimization: {
    splitChunks: {
      chunks: 'all'
    }
  }
};

Webpack анализирует пересечения графов и выделяет общие модули в отдельные чанки.

В результате структура сборки меняется:

  • home.bundle.js
  • admin.bundle.js
  • vendors~home~admin.js или аналогичный общий чанк

Таким образом достигается повторное использование кода между entry без дублирования.

runtime и его влияние на несколько entry

При наличии нескольких точек входа Webpack создаёт runtime-код, отвечающий за загрузку модулей и их связывание.

По умолчанию runtime может оказаться в каждом бандле, что также приводит к дублированию.

Для устранения этого используется:

module.exports = {
  optimization: {
    runtimeChunk: 'single'
  }
};

Это выделяет runtime в отдельный файл, который используется всеми entry.

Сценарии применения нескольких entry

Многостраничные приложения

Каждая страница является отдельной точкой входа. Такой подход соответствует архитектуре серверного рендеринга или классических web-приложений без SPA-ядра.

Изолированные части интерфейса

Иногда приложение содержит разные зоны, которые могут загружаться независимо:

  • административная панель
  • публичная часть
  • пользовательский кабинет

Каждая зона собирается как отдельный бандл.

Встраиваемые виджеты

Отдельные entry могут формировать независимые скрипты:

entry: {
  chatWidget: './src/widgets/chat.js',
  feedbackWidget: './src/widgets/feedback.js'
}

Такие бандлы могут подключаться на сторонних сайтах без загрузки основного приложения.

Управление зависимостями между entry

Несмотря на логическую изоляцию, иногда требуется разделять общий код вручную.

Типичная ошибка — создание скрытых зависимостей между entry через глобальные состояния или импорт одного entry в другой:

import './admin';

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

Правильная модель — вынос общего кода в отдельные модули, а не связывание entry между собой.

Динамическая композиция entry

Webpack позволяет задавать entry не только статически, но и динамически:

module.exports = {
  entry: () => ({
    home: './src/home.js',
    admin: './src/admin.js'
  })
};

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

Связь с HTML и загрузкой скриптов

При нескольких entry необходимо явно управлять подключением бандлов к HTML.

Обычно используется HtmlWebpackPlugin:

plugins: [
  new HtmlWebpackPlugin({
    chunks: ['home']
  })
]

Для каждой страницы указывается свой набор чанков, соответствующий её entry.

В многостраничной архитектуре обычно создаётся несколько HTML-файлов, каждый из которых привязан к своей точке входа.

Ограничения подхода нескольких entry

Несмотря на удобство, модель имеет ограничения:

  • усложнение конфигурации при росте числа страниц
  • необходимость контроля общих зависимостей
  • риск дублирования без оптимизации
  • сложность миграции к SPA-архитектуре

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

Поведение кеширования при нескольких entry

Разделение на entry напрямую влияет на стратегию кеширования в браузере. При корректной настройке имен файлов с хешами:

output: {
  filename: '[name].[contenthash].js'
}

изменения в одном entry не затрагивают другие, что позволяет:

  • сохранять кеш неизменённых частей
  • уменьшать объём повторных загрузок
  • ускорять повторные визиты

Особенно эффективно это работает в сочетании с выделением vendor и runtime чанков.

Связь нескольких entry с архитектурой приложения

Модель нескольких точек входа отражает архитектурное решение о разделении ответственности. Она фактически фиксирует границы модулей на уровне сборки.

Такая структура особенно характерна для:

  • серверно-рендеренных приложений с частичной интерактивностью
  • корпоративных систем с независимыми разделами
  • legacy-проектов, постепенно переходящих к модульной архитектуре

Webpack в этом случае выступает не только инструментом сборки, но и механизмом архитектурной сегментации кода.

Оглавление