Архитектура фронтенда
Пайплайны сборки: тест с выбором ответа
Суть Тест с выбором на синтез по всему юниту — стыки стадий, причины провала tree-shaking, dev/prod-паритет, content hashing и компромиссы скорости инструментов.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов поперёк всего юнита. Каждый отражает решение, которое ты принимаешь, пока бандл регрессирует, dev-only баг уезжает в прод или стадия сборки выбивает таймаут в CI — не определение для заучивания, а компромисс, который надо взвесить.
Цель
Убедись, что связываешь пять стадий пайплайна, причины провала tree-shaking, причины расхождения dev и prod и компромиссы content hashing и выбора инструмента — тот синтез, к которому вёл обзорный урок.
Викторина
Completed
Коллега меняет import debounce from 'lodash/debounce' на import _ from 'lodash', и основной бандл вырастает на ~200 KB. Почему tree-shaking не выкинул неиспользуемые функции?
Heads-up Tree-shaking включён по умолчанию в production-бандлах. Здесь его ломает формат модуля — экспорты CommonJS вычисляются в рантайме и не поддаются статическому анализу.
Heads-up Порядок стадий ни при чём. Даже при правильном порядке bundler держит весь CJS-модуль, потому что его экспорты не анализируемы статически.
Heads-up Стиль импорта не корень проблемы — формат модуля. ES-модули шейкаются независимо от default vs named; CommonJS не шейкается ни так, ни так.
Викторина
Completed
Чистая ESM-библиотека утилит всё равно тащит мёртвый код после сборки, хотя все импорты выглядят неиспользуемыми. Наиболее вероятная причина?
Heads-up Bundler шейкает ESM-графы любого размера. Размер ни при чём; модули держит именно отсутствующий контракт sideEffects.
Heads-up Tree-shaking удаляет неиспользуемые экспорты на уровне отдельных биндингов внутри модуля, не только целые файлы. Флаг sideEffects управляет тем, можно ли вообще выкинуть файл.
Heads-up Source map — это метаданные для отладки, эмитятся последними; они никогда не держат код в бандле. Рычаг — объявление sideEffects.
Викторина
Completed
Фича работает в dev-сервере Vite, но ломается после vite build. Какова наиболее вероятная структурная причина, а не разовая случайность?
Heads-up Устаревший кэш заставляет старое поведение сохраняться — противоположный симптом. Настоящий dev/prod-раскол — это два разных тулчейна, дающих разный вывод из одного исходника.
Heads-up Минификация иногда выявляет латентный баг, но структурная причина расхождения dev и prod в том, что они гоняют разные bundler-ы на по-разному сформированных графах модулей.
Heads-up Оба режима инлайнят env-переменные; расхождение здесь — архитектура сборки, не обработка env. Фикс — тестировать реальную prod-сборку, а не гоняться за инъекцией env.
Викторина
Completed
Почему замена Babel на esbuild или SWC срезает стадию transform на 90%+, а стадия bundle редко получает такое же ускорение?
Heads-up esbuild выдаёт корректный вывод; ускорение идёт от компилируемого языка, реальных потоков и единого общего AST — не от пропуска нужной работы.
Heads-up Формат конфига не влияет на стоимость рантайма. Babel медленный, потому что это однопоточный JavaScript, заново парсящий AST; стадия bundle остаётся последовательной при любом transformer.
Heads-up Bundling идёт по всему графу и в основном последователен — именно поэтому ускорения стадии transform на него не переносятся.
Викторина
Completed
Вернувшиеся пользователи перекачивают большой vendor-чанк при каждом деплое приложения, хотя React и зависимости не менялись. Фикс?
Heads-up Стабильные имена полностью ломают cache busting — пользователям отдавался бы устаревший код приложения. Фикс — границы чанков, а не удаление хэша.
Heads-up Частая ревалидация увеличивает трафик — противоположная цель. С content hashing нужен большой max-age плюс immutable; реальная проблема — vendor делит чанк с кодом приложения.
Heads-up Инлайн vendor в чанки приложения гарантирует, что его хэш меняется при каждом деплое, ломая кэш каждый раз — ровно та проблема, что здесь.
Викторина
Completed
Исходник — чистый ESM, но prod-бандл всё равно тащит целую зависимость, которую должен был отшейкать. Подозреваемая — стадия transform. Почему?
Heads-up Tree-shaking происходит на стадии bundle на графе модулей, а не во время пофайлового transform. Поломка на transform — это понижение ESM до CJS, которое убирает статическую структуру, нужную для shaking.
Heads-up Transform и minify — разные стадии; transform не минифицирует. Реальная поломка — понижение ESM до CommonJS до сборки.
Heads-up esbuild хорошо шейкает ESM; проблема в том, что Babel-transform может конвертировать ESM в CJS выше по течению, после чего ни один bundler не отшейкает.
Итог
Сквозная линия: сборка — это resolve → transform → bundle → minify → emit, и стыки между стадиями — это где живут баги. Tree-shaking требует статического ESM, поэтому его ломают CommonJS, необъявленные side effects и transform-ы, понижающие ESM до CJS до того, как bundler заглянет. Transform параллелен (поэтому там выигрывают компилируемые инструменты), а bundle остаётся последовательным. Dev и prod гоняют разные инструменты — валидируй реальную prod-сборку. И content hashing окупается только если отделить стабильный vendor-код от часто меняющегося кода приложения.