Архитектура фронтенда
Пайплайны сборки: тест на свободное припоминание
Припоминание бьёт перечитывание. Для каждого промпта скажи или запиши полный ответ по памяти, прежде чем открыть модельный — именно усилие припоминания закрепляет материал.
Восстанови ключевые механизмы юнита — пять стадий, почему проваливается tree-shaking, dev/prod-раскол, content hashing, source map и build cache — не подглядывая в обзор.
- 01Назови пять стадий пайплайна сборки по порядку и скажи, какая параллельна, а какая последовательна.
- 02Tree-shaking работает только на статических ES-модулях. Какие три вещи его ломают и как чинить каждую?
- 03Почему случаются баги 'работает в dev, ломается в prod' с инструментами вроде Vite, и как senior их предотвращает?
- 04Объясни content hashing и ошибку с vendor-чанком, которую он вскрывает.
- 05Что делают source map, какую настройку использовать в production и почему?
- 06Как build cache ускоряет CI и в чём разница между кэшем по content-hash и персистентным build cache?
Если ты смог восстановить каждый ответ по памяти, ты держишь стержень юнита: сборка — это пять стадий (resolve, transform, bundle, minify, emit) с параллельным transform и последовательным bundle; tree-shaking требует статического ESM и ломается CommonJS, необъявленными side effects и понижением ESM до CJS; dev и prod гоняют разные инструменты, поэтому валидируй реальную prod-сборку; content hashing плюс отдельный vendor-чанк дают кэш на год; hidden source map делают prod-ошибки читаемыми без утечки исходника; а персистентный build cache по ключу входов — то, что ускоряет CI, в отличие от content hashing вывода.