Пайплайны сборки: аудит и упрочнение реальной сборки

Возьми реальное фронтенд-приложение (своё или стартер, который ты соберёшь с намеренно CommonJS-тяжёлой зависимостью) и упрочни его сборку: сократи production-бандл, устранив регрессию tree-shaking, стабилизируй кэш разбиением vendor, закрой один разрыв dev/prod-паритета и докажи каждый фикс числами до/после.

• Подними сборку на Vite (или webpack) и сними baseline: размер production-бандла по чанкам, всего переданных байт и wall-clock сборки (холодная и тёплая). Используй bundle analyzer (rollup-plugin-visualizer / webpack-bundle-analyzer) и сохрани baseline-treemap.
• Введи или найди регрессию tree-shaking: импортируй утилиту из CommonJS-пакета широким способом (например, import _ from 'lodash') и подтверди по analyzer, что уехала вся библиотека. Затем почини через ESM-сборку или глубокие импорты и переизмерь.
• Проверь поле sideEffects в package.json хотя бы одного пакета воркспейса: убедись, что модули с импортом CSS или полифиллов перечислены, и покажи, что слишком широкий sideEffects: false выкинул бы стилизацию (или что честное объявление её сохраняет).
• Настрой production правильно: собирай в режиме production, чтобы запустились минификация и dead-code-elimination веток под NODE_ENV, и выставь hidden source map, чтобы трейсы оставались читаемыми в трекере ошибок без публичного раскрытия исходника.
• Вынеси vendor (фреймворк + крупные стабильные зависимости) в свой content-hashed чанк через manualChunks/splitChunks, затем сделай однострочное изменение в приложении, пересобери и покажи, что хэш vendor-чанка НЕ изменился, а хэш чанка приложения изменился.
• Воспроизведи и закрой один разрыв dev/prod-паритета: найди поведение, отличающееся между dev-сервером и собранным выводом (или сконструируй его циклическим импортом), добавь шаг CI, который гоняет реальную production-сборку и smoke-тест по vite preview, и покажи, что гейт падает на баге до фикса.
• Включи и проверь build cache: включи filesystem/персистентный кэш, прогони холодную, затем тёплую сборку и зафиксируй ускорение тёплой. Подтверди, что ключ кэша включает версию инструмента, чтобы апгрейд его инвалидировал.

• Таблица до/после: всего байт бандла, размеры vendor vs app чанков, время холодной vs тёплой сборки и вклад регрессии tree-shaking — всё измерено из analyzer и вывода сборки, не оценено.
• Treemap-ы analyzer до и после ясно показывают, что CommonJS-регрессия ушла, а vendor изолирован в свой чанк.
• Доказательство стабильности кэша: две подряд сборки с изменением только в коде приложения, показывающие неизменное имя (хэш) vendor-чанка в обеих.
• Лог прогона CI, показывающий, что smoke-тест production-сборки ловит баг паритета, а затем проходит после фикса.
• Абзац-описание, называющий, какую стадию пайплайна целил каждый фикс (resolve/transform/bundle/minify/emit) и почему это была верная стадия.