Какие изменения вносились в конфигурацию webpack и зачем?

Что проверяют

Работали ли вы со сборкой руками или только запускали готовый шаблон. Интервьюеру важна связка «проблема, правка, измеренный результат». Следом почти всегда спрашивают, как вы поняли, что правка помогла, и чем мерили размер бандла.

Как отвечать

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

• долгосрочное кэширование: имена файлов с [contenthash], optimization.runtimeChunk: 'single' и splitChunks.cacheGroups для вендоров, чтобы после релиза браузер перекачивал только изменившийся код;
• тяжёлый бандл: webpack-bundle-analyzer показал лишнее, дальше ленивые import() для маршрутов, замена тяжёлой библиотеки дат, IgnorePlugin для ненужных локалей;
• скорость сборки: cache: { type: 'filesystem' } в webpack 5, замена babel-loader на swc-loader или esbuild-loader;
• миграция на webpack 5: file-loader и url-loader заменяются встроенными asset modules (type: 'asset/resource'), полифилы Node.js больше не подставляются сами, их добавляют через resolve.fallback;
• окружения: раздельные конфиги через webpack-merge, DefinePlugin для переменных, devServer.proxy для API.

Хорошо звучит оговорка, что mode: 'production' уже включает минификацию через Terser, и отдельный TerserPlugin нужен только ради своих настроек.

Если конфиг прятал фреймворк, так и скажите и опишите, что меняли через его точку расширения. Если проект уже переехал на Vite или Rspack, объясните, что заставило уйти.

Где спотыкаются

Пересказывают документацию: «добавил лоадеры и плагины». Без причины и результата это звучит как чужой опыт.

Путают hash, chunkhash и contenthash и не могут объяснить, почему после релиза у пользователей висел старый код.

Отдают в продакшен devtool: 'eval-source-map' или публичные source maps, а потом удивляются размеру бандла и утечке исходников.