JAVASCRIPT
#webpack#webpack5#config#frontend#build#babel#production

Webpack 5: production-ориентированный webpack.config.js (2026)

Минимальный конфиг Webpack 5 для production-сборки: mode production, entry/output с contenthash, filesystem cache, resolve.extensions, базовая обработка JS/TS через babel-loader. Только официальный API, без устаревших опций.

Как использовать

  1. Скопировать в корень проекта как webpack.config.js
  2. Установить зависимости: npm i -D webpack webpack-cli babel-loader @babel/core @babel/preset-env @babel/preset-typescript
  3. Добавить .babelrc или babel.config.js с presets: @babel/preset-env, @babel/preset-typescript (и при необходимости @babel/preset-react)
  4. Для CSS — добавить css-loader и style-loader или mini-css-extract-plugin

Конфигурация использует только официальный API Webpack 5 (webpack.js.org/configuration), без deprecated loaders и устаревших опций.

const path = require('node:path');

module.exports = {
  // --- Режим сборки ---
  // production включает минификацию (Terser), tree shaking, убирает лишний код.
  // Без этого прод-сборка будет тяжёлой и медленной в рантайме.
  mode: 'production',

  // --- Точка входа ---
  entry: './src/index.js',

  // --- Выход ---
  output: {
    path: path.resolve(__dirname, 'dist'),
    // [contenthash] — хэш от содержимого чанка. При неизменном коде имя файла не меняется —
    // браузер кэширует, при деплое только изменённые чанки подтягиваются заново.
    filename: '[name].[contenthash].js',
    // Имена для асинхронных чанков (dynamic import). Тоже contenthash для долгого кэша.
    chunkFilename: '[name].[contenthash].js',
    // Очищать dist перед каждой сборкой (встроено в Webpack 5.20+, не нужен CleanWebpackPlugin).
    clean: true,
  },

  // --- Кэш на диск (критично для скорости повторных сборок) ---
  // В production по умолчанию кэш выключен. type: "filesystem" сохраняет кэш между запусками:
  // повторный build пересобирает только изменённые модули, холодный старт быстрее в разы.
  cache: {
    type: 'filesystem',
    // Инвалидировать кэш при изменении конфига или его зависимостей (путь к этому файлу).
    buildDependencies: {
      config: [__filename],
    },
  },

  // --- Разрешение модулей ---
  resolve: {
    // Порядок важен: при import без расширения Webpack перебирает слева направо.
    // .ts и .tsx в начале — чтобы не подхватывать .js раньше TypeScript.
    extensions: ['.ts', '.tsx', '.js', '.jsx', '.json'],
  },

  // --- Обработка файлов ---
  module: {
    rules: [
      {
        test: /\.[tj]sx?$/,
        exclude: /node_modules/,
        use: 'babel-loader',
        // Babel: транспиляция ES+/TS в целевой формат. Настройка в .babelrc или babel.config.js
        // (presets: @babel/preset-env, @babel/preset-typescript; для JSX — @babel/preset-react).
      },
    ],
  },
};

Файл класть в корень проекта как webpack.config.js. Для CSS добавь правило с css-loader и style-loader (или mini-css-extract-plugin для prod).

Почему filesystem cache критичен для Webpack

В development Webpack по умолчанию использует кэш в памяти (cache.type: 'memory'), в production кэш по умолчанию отключён. Без cache: { type: 'filesystem' } каждый прод-билд — полный пересбор графа: все модули заново парсятся, транспилируются, обрабатываются лоадерами. На больших проектах это минуты вместо десятков секунд.

Filesystem cache сохраняет результат работы лоадеров и разбор модулей на диск (по умолчанию node_modules/.cache/webpack). При следующем запуске пересчитываются только изменённые файлы и зависящие от них чанки. В CI можно кэшировать эту директорию между прогонами (тот же путь, тот же ключ кэша), чтобы ускорять сборки. Без него Webpack в проде ведёт себя как «каждый раз с нуля» — для 2026 года это недопустимо медленно.

В каких проектах Webpack до сих пор оправдан

  • Крупный legacy — уже собран на Webpack, куча лоадеров и плагинов (SVG, шрифты, i18n, специфичные трансформации). Миграция на Vite/esbuild — риск и трудозатраты; проще держать Webpack 5 и включить filesystem cache.
  • Микрофронты / Module Federation — экосистема и туториалы в основном на Webpack; shared-зависимости и удалённые entry удобно настраивать там, где это изначально заложено.
  • Жёсткие требования к пайплайну — кастомный чанкинг, тонкая настройка оптимизаций (splitChunks, порядок плагинов), интеграция с внутренними инструментами. Гибкость Webpack платится конфигом и скоростью, но в таких кейсах она нужна.
  • Команда и кодовая база уже на Webpack — без бизнес-причины переходить на Vite не обязательно: достаточно обновляться до Webpack 5, включить кэш и при необходимости оптимизировать конфиг по Build Performance.

Для новых зелёных проектов без перечисленных требований обычно разумнее брать Vite или (для Next) Turbopack: быстрее dev, проще конфиг, меньше «магии» лоадеров.

Похожие сниппеты