Перейти к основному содержимому

Package Managers и Bundlers

Экспресс-шпаргалка 20/20​

  1. npm/pnpm/yarn различаются стратегией хранения зависимостей, скоростью установки и удобством в монорепах.
  2. Lockfile фиксирует точное дерево зависимостей и обеспечивает воспроизводимые сборки.
  3. npm ci ставит строго по lockfile, быстрее и стабильнее для CI, чем npm install.
  4. Semver определяет совместимость версий, но диапазоны могут неожиданно подтянуть breaking changes.
  5. peerDependencies декларируют совместимость с хост-пакетом; конфликты требуют выравнивания версий.
  6. Workspaces позволяют централизованно управлять зависимостями и пакетами в монорепозитории.
  7. Обновление зависимостей делается поэтапно с changelog-review, тестами и rollback планом.
  8. Vite обычно быстрее в dev, Webpack часто гибче в сложных enterprise-конфигах.
  9. Tree shaking работает при ESM, корректных imports и правильном sideEffects.
  10. Code splitting разбивает бандл на чанки и снижает стартовую загрузку JS.
  11. Анализ бандла делают через visualizer/stats, чтобы найти тяжёлые или дублирующиеся зависимости.
  12. HMR может ломаться из-за stateful side effects и нестабильных boundaries.
  13. Env-переменные в бандле нужно разделять на публичные и приватные, чтобы не утекали секреты.
  14. Source maps нужны для прод-диагностики, но доступ к ним надо ограничивать.
  15. CI ускоряют кэшированием, параллелизацией и уменьшением лишних шагов pipeline.
  16. Кэширование ассетов строится на content hash + immutable cache headers.
  17. Release pipeline включает quality gates: lint, typecheck, tests, build, smoke.
  18. Vulnerability management: регулярный аудит, patch policy и контроль транзитивных пакетов.
  19. Anti-patternы конфига: неуправляемые плагины, хаос alias/loaders и отсутствие budget.
  20. Миграция Webpack -> Vite делается поэтапно с проверкой build parity и метрик.

1. В чем разница npm, pnpm и yarn на практике?​

Теги: tooling, build, package-manager Сложность: Middle/Senior

Короткий ответ​

npm/pnpm/yarn различаются стратегией хранения зависимостей, скоростью установки и удобством в монорепах.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для стабильного CI/CD, предсказуемых релизов и контролируемого размера бандла.
  2. Главный риск: Непредсказуемые версии и нефиксированные зависимости создают flaky CI и риск внезапных поломок сборки.
  3. Как проверяете решение: Проверяю pipeline на тестовом релизе: время, стабильность и rollback-сценарий с измеримыми критериями.

Мини-пример​

// package.json
{
  "scripts": {
    "build": "vite build",
    "test": "vitest run"
  }
}

Углубление (2-3 минуты)​

  1. Свяжите тему "В чем разница npm, pnpm и yarn на практике?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Покажите, как решение сокращает lead time или снижает change failure rate.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Добавляют проверки в CI без учета времени обратной связи команды.
  2. Деплоят без заранее описанного rollback-плана.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Как измерите влияние изменения на lead time и CFR?
  2. Какой сигнал в мониторинге станет trigger для rollback?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Структуру CI/CD и обязательные quality gates.
  2. Метрики процесса: lead time, CFR, flaky rate.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Package Managers и Bundlers
  2. Обучение: Tooling и Delivery
  3. Карта подготовки: Package Managers

2. Зачем нужен lockfile и почему его нельзя игнорировать?​

Теги: tooling, build, package-manager Сложность: Middle/Senior

Короткий ответ​

Lockfile фиксирует точное дерево зависимостей и обеспечивает воспроизводимые сборки.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для стабильного CI/CD, предсказуемых релизов и контролируемого размера бандла.
  2. Главный риск: Непредсказуемые версии и нефиксированные зависимости создают flaky CI и риск внезапных поломок сборки.
  3. Как проверяете решение: Прогоняю smoke + observability checklist и убеждаюсь, что релизные критерии выполняются автоматически.

Мини-пример​

// package.json
{
  "scripts": {
    "build": "vite build",
    "test": "vitest run"
  }
}

Углубление (2-3 минуты)​

  1. Свяжите тему "Зачем нужен lockfile и почему его нельзя игнорировать?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Опишите минимальные quality gates и критерии rollback.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Игнорируют flaky-тесты, из-за чего quality signal теряет доверие.
  2. Добавляют проверки в CI без учета времени обратной связи команды.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Как измерите влияние изменения на lead time и CFR?
  2. Какой сигнал в мониторинге станет trigger для rollback?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Структуру CI/CD и обязательные quality gates.
  2. Метрики процесса: lead time, CFR, flaky rate.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Package Managers и Bundlers
  2. Обучение: Tooling и Delivery
  3. Карта подготовки: Package Managers

3. Разница npm install и npm ci?​

Теги: tooling, build, package-manager Сложность: Middle/Senior

Короткий ответ​

npm ci ставит строго по lockfile, быстрее и стабильнее для CI, чем npm install.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для стабильного CI/CD, предсказуемых релизов и контролируемого размера бандла.
  2. Главный риск: Непредсказуемые версии и нефиксированные зависимости создают flaky CI и риск внезапных поломок сборки.
  3. Как проверяете решение: Сравниваю lead time и change failure rate до/после изменения процесса и фиксирую результат в runbook.

Мини-пример​

// package.json
{
  "scripts": {
    "build": "vite build",
    "test": "vitest run"
  }
}

Углубление (2-3 минуты)​

  1. Свяжите тему "Разница npm install и npm ci?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Привяжите тему к delivery-риску: что ломается в CI/CD без этого решения.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Добавляют проверки в CI без учета времени обратной связи команды.
  2. Игнорируют flaky-тесты, из-за чего quality signal теряет доверие.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Какие quality gates обязательны перед релизом этой зоны?
  2. Как измерите влияние изменения на lead time и CFR?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Структуру CI/CD и обязательные quality gates.
  2. План rollout/rollback и критерии остановки релиза.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Package Managers и Bundlers
  2. Обучение: Tooling и Delivery
  3. Карта подготовки: Package Managers

4. Как работает semver и риски диапазонов версий?​

Теги: tooling, build Сложность: Middle/Senior

Короткий ответ​

Semver определяет совместимость версий, но диапазоны могут неожиданно подтянуть breaking changes.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для стабильного CI/CD, предсказуемых релизов и контролируемого размера бандла.
  2. Главный риск: Непредсказуемые версии и нефиксированные зависимости создают flaky CI и риск внезапных поломок сборки.
  3. Как проверяете решение: Прогоняю smoke + observability checklist и убеждаюсь, что релизные критерии выполняются автоматически.

Мини-пример​

// package.json
{
  "scripts": {
    "build": "vite build",
    "test": "vitest run"
  }
}

Углубление (2-3 минуты)​

  1. Свяжите тему "Как работает semver и риски диапазонов версий?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Покажите, как решение сокращает lead time или снижает change failure rate.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Деплоят без заранее описанного rollback-плана.
  2. Игнорируют flaky-тесты, из-за чего quality signal теряет доверие.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Как измерите влияние изменения на lead time и CFR?
  2. Какие quality gates обязательны перед релизом этой зоны?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Метрики процесса: lead time, CFR, flaky rate.
  2. План rollout/rollback и критерии остановки релиза.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Package Managers и Bundlers
  2. Обучение: Tooling и Delivery
  3. Карта подготовки: Package Managers

5. Что такое peerDependencies и как решать конфликты?​

Теги: tooling, build Сложность: Middle/Senior

Короткий ответ​

peerDependencies декларируют совместимость с хост-пакетом; конфликты требуют выравнивания версий.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для стабильного CI/CD, предсказуемых релизов и контролируемого размера бандла.
  2. Главный риск: Непредсказуемые версии и нефиксированные зависимости создают flaky CI и риск внезапных поломок сборки.
  3. Как проверяете решение: Проверяю pipeline на тестовом релизе: время, стабильность и rollback-сценарий с измеримыми критериями.

Мини-пример​

// package.json
{
  "scripts": {
    "build": "vite build",
    "test": "vitest run"
  }
}

Углубление (2-3 минуты)​

  1. Свяжите тему "Что такое peerDependencies и как решать конфликты?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Привяжите тему к delivery-риску: что ломается в CI/CD без этого решения.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Игнорируют flaky-тесты, из-за чего quality signal теряет доверие.
  2. Деплоят без заранее описанного rollback-плана.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Какие quality gates обязательны перед релизом этой зоны?
  2. Как измерите влияние изменения на lead time и CFR?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. План rollout/rollback и критерии остановки релиза.
  2. Структуру CI/CD и обязательные quality gates.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Package Managers и Bundlers
  2. Обучение: Tooling и Delivery
  3. Карта подготовки: Package Managers

6. Когда применять workspaces в монорепозитории?​

Теги: tooling, build Сложность: Middle/Senior

Короткий ответ​

Workspaces позволяют централизованно управлять зависимостями и пакетами в монорепозитории.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для стабильного CI/CD, предсказуемых релизов и контролируемого размера бандла.
  2. Главный риск: Непредсказуемые версии и нефиксированные зависимости создают flaky CI и риск внезапных поломок сборки.
  3. Как проверяете решение: Проверяю pipeline на тестовом релизе: время, стабильность и rollback-сценарий с измеримыми критериями.

Мини-пример​

{
  "private": true,
  "workspaces": ["apps/*", "packages/*"]
}

Углубление (2-3 минуты)​

  1. Свяжите тему "Когда применять workspaces в монорепозитории?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Опишите минимальные quality gates и критерии rollback.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Добавляют проверки в CI без учета времени обратной связи команды.
  2. Игнорируют flaky-тесты, из-за чего quality signal теряет доверие.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Какой сигнал в мониторинге станет trigger для rollback?
  2. Какие quality gates обязательны перед релизом этой зоны?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Метрики процесса: lead time, CFR, flaky rate.
  2. План rollout/rollback и критерии остановки релиза.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Package Managers и Bundlers
  2. Обучение: Tooling и Delivery
  3. Карта подготовки: Package Managers

7. Как безопасно обновлять зависимости в большом проекте?​

Теги: tooling, build Сложность: Middle/Senior

Короткий ответ​

Обновление зависимостей делается поэтапно с changelog-review, тестами и rollback планом.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для стабильного CI/CD, предсказуемых релизов и контролируемого размера бандла.
  2. Главный риск: Непредсказуемые версии и нефиксированные зависимости создают flaky CI и риск внезапных поломок сборки.
  3. Как проверяете решение: Проверяю pipeline на тестовом релизе: время, стабильность и rollback-сценарий с измеримыми критериями.

Мини-пример​

// package.json
{
  "scripts": {
    "build": "vite build",
    "test": "vitest run"
  }
}

Углубление (2-3 минуты)​

  1. Свяжите тему "Как безопасно обновлять зависимости в большом проекте?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Привяжите тему к delivery-риску: что ломается в CI/CD без этого решения.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Игнорируют flaky-тесты, из-за чего quality signal теряет доверие.
  2. Деплоят без заранее описанного rollback-плана.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Какие quality gates обязательны перед релизом этой зоны?
  2. Как измерите влияние изменения на lead time и CFR?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. План rollout/rollback и критерии остановки релиза.
  2. Структуру CI/CD и обязательные quality gates.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Package Managers и Bundlers
  2. Обучение: Tooling и Delivery
  3. Карта подготовки: Package Managers

8. Как выбирать между Vite и Webpack?​

Теги: tooling, build, bundlers Сложность: Middle/Senior

Короткий ответ​

Vite обычно быстрее в dev, Webpack часто гибче в сложных enterprise-конфигах.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для стабильного CI/CD, предсказуемых релизов и контролируемого размера бандла.
  2. Главный риск: Оптимизация без измерений может ухудшить DX и не дать эффекта на реальных метриках.
  3. Как проверяете решение: Проверяю pipeline на тестовом релизе: время, стабильность и rollback-сценарий с измеримыми критериями.

Мини-пример​

// package.json
{
  "scripts": {
    "build": "vite build",
    "test": "vitest run"
  }
}

Углубление (2-3 минуты)​

  1. Свяжите тему "Как выбирать между Vite и Webpack?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Привяжите тему к delivery-риску: что ломается в CI/CD без этого решения.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Добавляют проверки в CI без учета времени обратной связи команды.
  2. Деплоят без заранее описанного rollback-плана.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Какие quality gates обязательны перед релизом этой зоны?
  2. Как измерите влияние изменения на lead time и CFR?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Структуру CI/CD и обязательные quality gates.
  2. План rollout/rollback и критерии остановки релиза.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Package Managers и Bundlers
  2. Обучение: Tooling и Delivery
  3. Карта подготовки: Package Managers

9. От чего зависит tree shaking?​

Теги: tooling, build Сложность: Middle/Senior

Короткий ответ​

Tree shaking работает при ESM, корректных imports и правильном sideEffects.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для стабильного CI/CD, предсказуемых релизов и контролируемого размера бандла.
  2. Главный риск: Непредсказуемые версии и нефиксированные зависимости создают flaky CI и риск внезапных поломок сборки.
  3. Как проверяете решение: Проверяю pipeline на тестовом релизе: время, стабильность и rollback-сценарий с измеримыми критериями.

Мини-пример​

// less effective
import _ from 'lodash';
// better for bundle size
import debounce from 'lodash/debounce';

Углубление (2-3 минуты)​

  1. Свяжите тему "От чего зависит tree shaking?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Опишите минимальные quality gates и критерии rollback.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Игнорируют flaky-тесты, из-за чего quality signal теряет доверие.
  2. Добавляют проверки в CI без учета времени обратной связи команды.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Как измерите влияние изменения на lead time и CFR?
  2. Какие quality gates обязательны перед релизом этой зоны?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. План rollout/rollback и критерии остановки релиза.
  2. Метрики процесса: lead time, CFR, flaky rate.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Package Managers и Bundlers
  2. Обучение: Tooling и Delivery
  3. Карта подготовки: Package Managers

10. Как организовать code splitting и chunk strategy?​

Теги: tooling, build Сложность: Middle/Senior

Короткий ответ​

Code splitting разбивает бандл на чанки и снижает стартовую загрузку JS.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для стабильного CI/CD, предсказуемых релизов и контролируемого размера бандла.
  2. Главный риск: Непредсказуемые версии и нефиксированные зависимости создают flaky CI и риск внезапных поломок сборки.
  3. Как проверяете решение: Прогоняю smoke + observability checklist и убеждаюсь, что релизные критерии выполняются автоматически.

Мини-пример​

// package.json
{
  "scripts": {
    "build": "vite build",
    "test": "vitest run"
  }
}

Углубление (2-3 минуты)​

  1. Свяжите тему "Как организовать code splitting и chunk strategy?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Опишите минимальные quality gates и критерии rollback.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Игнорируют flaky-тесты, из-за чего quality signal теряет доверие.
  2. Деплоят без заранее описанного rollback-плана.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Как измерите влияние изменения на lead time и CFR?
  2. Какие quality gates обязательны перед релизом этой зоны?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Метрики процесса: lead time, CFR, flaky rate.
  2. План rollout/rollback и критерии остановки релиза.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Package Managers и Bundlers
  2. Обучение: Tooling и Delivery
  3. Карта подготовки: Package Managers

11. Как анализировать размер бандла и находить причины роста?​

Теги: tooling, build, bundlers Сложность: Middle/Senior

Короткий ответ​

Анализ бандла делают через visualizer/stats, чтобы найти тяжёлые или дублирующиеся зависимости.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для стабильного CI/CD, предсказуемых релизов и контролируемого размера бандла.
  2. Главный риск: Непредсказуемые версии и нефиксированные зависимости создают flaky CI и риск внезапных поломок сборки.
  3. Как проверяете решение: Прогоняю smoke + observability checklist и убеждаюсь, что релизные критерии выполняются автоматически.

Мини-пример​

// package.json
{
  "scripts": {
    "build": "vite build",
    "test": "vitest run"
  }
}

Углубление (2-3 минуты)​

  1. Свяжите тему "Как анализировать размер бандла и находить причины роста?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Покажите, как решение сокращает lead time или снижает change failure rate.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Игнорируют flaky-тесты, из-за чего quality signal теряет доверие.
  2. Деплоят без заранее описанного rollback-плана.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Какие quality gates обязательны перед релизом этой зоны?
  2. Как измерите влияние изменения на lead time и CFR?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Структуру CI/CD и обязательные quality gates.
  2. План rollout/rollback и критерии остановки релиза.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Package Managers и Bundlers
  2. Обучение: Tooling и Delivery
  3. Карта подготовки: Package Managers

12. Как работает HMR и почему иногда ломается?​

Теги: tooling, build Сложность: Middle/Senior

Короткий ответ​

HMR может ломаться из-за stateful side effects и нестабильных boundaries.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для стабильного CI/CD, предсказуемых релизов и контролируемого размера бандла.
  2. Главный риск: Непредсказуемые версии и нефиксированные зависимости создают flaky CI и риск внезапных поломок сборки.
  3. Как проверяете решение: Прогоняю smoke + observability checklist и убеждаюсь, что релизные критерии выполняются автоматически.

Мини-пример​

// package.json
{
  "scripts": {
    "build": "vite build",
    "test": "vitest run"
  }
}

Углубление (2-3 минуты)​

  1. Свяжите тему "Как работает HMR и почему иногда ломается?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Опишите минимальные quality gates и критерии rollback.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Добавляют проверки в CI без учета времени обратной связи команды.
  2. Игнорируют flaky-тесты, из-за чего quality signal теряет доверие.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Как измерите влияние изменения на lead time и CFR?
  2. Какие quality gates обязательны перед релизом этой зоны?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. План rollout/rollback и критерии остановки релиза.
  2. Метрики процесса: lead time, CFR, flaky rate.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Package Managers и Bundlers
  2. Обучение: Tooling и Delivery
  3. Карта подготовки: Package Managers

13. Как правильно работать с env переменными в сборке?​

Теги: tooling, build Сложность: Middle/Senior

Короткий ответ​

Env-переменные в бандле нужно разделять на публичные и приватные, чтобы не утекали секреты.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для стабильного CI/CD, предсказуемых релизов и контролируемого размера бандла.
  2. Главный риск: Непредсказуемые версии и нефиксированные зависимости создают flaky CI и риск внезапных поломок сборки.
  3. Как проверяете решение: Проверяю pipeline на тестовом релизе: время, стабильность и rollback-сценарий с измеримыми критериями.

Мини-пример​

// package.json
{
  "scripts": {
    "build": "vite build",
    "test": "vitest run"
  }
}

Углубление (2-3 минуты)​

  1. Свяжите тему "Как правильно работать с env переменными в сборке?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Покажите, как решение сокращает lead time или снижает change failure rate.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Добавляют проверки в CI без учета времени обратной связи команды.
  2. Деплоят без заранее описанного rollback-плана.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Какие quality gates обязательны перед релизом этой зоны?
  2. Как измерите влияние изменения на lead time и CFR?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. План rollout/rollback и критерии остановки релиза.
  2. Структуру CI/CD и обязательные quality gates.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Package Managers и Bundlers
  2. Обучение: Tooling и Delivery
  3. Карта подготовки: Package Managers

14. Что такое source maps и как использовать их в проде?​

Теги: tooling, build Сложность: Middle/Senior

Короткий ответ​

Source maps нужны для прод-диагностики, но доступ к ним надо ограничивать.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для стабильного CI/CD, предсказуемых релизов и контролируемого размера бандла.
  2. Главный риск: Непредсказуемые версии и нефиксированные зависимости создают flaky CI и риск внезапных поломок сборки.
  3. Как проверяете решение: Сравниваю lead time и change failure rate до/после изменения процесса и фиксирую результат в runbook.

Мини-пример​

// package.json
{
  "scripts": {
    "build": "vite build",
    "test": "vitest run"
  }
}

Углубление (2-3 минуты)​

  1. Свяжите тему "Что такое source maps и как использовать их в проде?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Привяжите тему к delivery-риску: что ломается в CI/CD без этого решения.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Деплоят без заранее описанного rollback-плана.
  2. Добавляют проверки в CI без учета времени обратной связи команды.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Какие quality gates обязательны перед релизом этой зоны?
  2. Какой сигнал в мониторинге станет trigger для rollback?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Метрики процесса: lead time, CFR, flaky rate.
  2. Структуру CI/CD и обязательные quality gates.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Package Managers и Bundlers
  2. Обучение: Tooling и Delivery
  3. Карта подготовки: Package Managers

15. Как ускорять CI сборки frontend-проекта?​

Теги: tooling, build Сложность: Middle/Senior

Короткий ответ​

CI ускоряют кэшированием, параллелизацией и уменьшением лишних шагов pipeline.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для стабильного CI/CD, предсказуемых релизов и контролируемого размера бандла.
  2. Главный риск: Непредсказуемые версии и нефиксированные зависимости создают flaky CI и риск внезапных поломок сборки.
  3. Как проверяете решение: Сравниваю lead time и change failure rate до/после изменения процесса и фиксирую результат в runbook.

Мини-пример​

// package.json
{
  "scripts": {
    "build": "vite build",
    "test": "vitest run"
  }
}

Углубление (2-3 минуты)​

  1. Свяжите тему "Как ускорять CI сборки frontend-проекта?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Опишите минимальные quality gates и критерии rollback.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Игнорируют flaky-тесты, из-за чего quality signal теряет доверие.
  2. Добавляют проверки в CI без учета времени обратной связи команды.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Какой сигнал в мониторинге станет trigger для rollback?
  2. Какие quality gates обязательны перед релизом этой зоны?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Метрики процесса: lead time, CFR, flaky rate.
  2. План rollout/rollback и критерии остановки релиза.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Package Managers и Bundlers
  2. Обучение: Tooling и Delivery
  3. Карта подготовки: Package Managers

16. Как проектировать кэширование статических ассетов?​

Теги: tooling, build, cache Сложность: Middle/Senior

Короткий ответ​

Кэширование ассетов строится на content hash + immutable cache headers.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для стабильного CI/CD, предсказуемых релизов и контролируемого размера бандла.
  2. Главный риск: Без стратегии инвалидации кэш становится источником stale-данных и трудноуловимых багов.
  3. Как проверяете решение: Сравниваю lead time и change failure rate до/после изменения процесса и фиксирую результат в runbook.

Мини-пример​

// package.json
{
  "scripts": {
    "build": "vite build",
    "test": "vitest run"
  }
}

Углубление (2-3 минуты)​

  1. Свяжите тему "Как проектировать кэширование статических ассетов?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Покажите, как решение сокращает lead time или снижает change failure rate.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Деплоят без заранее описанного rollback-плана.
  2. Добавляют проверки в CI без учета времени обратной связи команды.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Какие quality gates обязательны перед релизом этой зоны?
  2. Какой сигнал в мониторинге станет trigger для rollback?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Метрики процесса: lead time, CFR, flaky rate.
  2. Структуру CI/CD и обязательные quality gates.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Package Managers и Bundlers
  2. Обучение: Tooling и Delivery
  3. Карта подготовки: Package Managers

17. Как организовать release pipeline с quality gates?​

Теги: tooling, build Сложность: Middle/Senior

Короткий ответ​

Release pipeline включает quality gates: lint, typecheck, tests, build, smoke.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для стабильного CI/CD, предсказуемых релизов и контролируемого размера бандла.
  2. Главный риск: Непредсказуемые версии и нефиксированные зависимости создают flaky CI и риск внезапных поломок сборки.
  3. Как проверяете решение: Сравниваю lead time и change failure rate до/после изменения процесса и фиксирую результат в runbook.

Мини-пример​

// package.json
{
  "scripts": {
    "build": "vite build",
    "test": "vitest run"
  }
}

Углубление (2-3 минуты)​

  1. Свяжите тему "Как организовать release pipeline с quality gates?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Покажите, как решение сокращает lead time или снижает change failure rate.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Добавляют проверки в CI без учета времени обратной связи команды.
  2. Деплоят без заранее описанного rollback-плана.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Какой сигнал в мониторинге станет trigger для rollback?
  2. Какие quality gates обязательны перед релизом этой зоны?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Метрики процесса: lead time, CFR, flaky rate.
  2. Структуру CI/CD и обязательные quality gates.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Package Managers и Bundlers
  2. Обучение: Tooling и Delivery
  3. Карта подготовки: Package Managers

18. Как обрабатывать security vulnerabilities в пакетах?​

Теги: tooling, build Сложность: Middle/Senior

Короткий ответ​

Vulnerability management: регулярный аудит, patch policy и контроль транзитивных пакетов.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для стабильного CI/CD, предсказуемых релизов и контролируемого размера бандла.
  2. Главный риск: Непредсказуемые версии и нефиксированные зависимости создают flaky CI и риск внезапных поломок сборки.
  3. Как проверяете решение: Сравниваю lead time и change failure rate до/после изменения процесса и фиксирую результат в runbook.

Мини-пример​

// package.json
{
  "scripts": {
    "build": "vite build",
    "test": "vitest run"
  }
}

Углубление (2-3 минуты)​

  1. Свяжите тему "Как обрабатывать security vulnerabilities в пакетах?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Покажите, как решение сокращает lead time или снижает change failure rate.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Деплоят без заранее описанного rollback-плана.
  2. Добавляют проверки в CI без учета времени обратной связи команды.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Как измерите влияние изменения на lead time и CFR?
  2. Какой сигнал в мониторинге станет trigger для rollback?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Структуру CI/CD и обязательные quality gates.
  2. Метрики процесса: lead time, CFR, flaky rate.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Package Managers и Bundlers
  2. Обучение: Tooling и Delivery
  3. Карта подготовки: Package Managers

19. Какие anti-patterns бывают в конфигурации bundler?​

Теги: tooling, build, bundlers Сложность: Middle/Senior

Короткий ответ​

Anti-patternы конфига: неуправляемые плагины, хаос alias/loaders и отсутствие budget.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для стабильного CI/CD, предсказуемых релизов и контролируемого размера бандла.
  2. Главный риск: Оптимизация без измерений может ухудшить DX и не дать эффекта на реальных метриках.
  3. Как проверяете решение: Прогоняю smoke + observability checklist и убеждаюсь, что релизные критерии выполняются автоматически.

Мини-пример​

// package.json
{
  "scripts": {
    "build": "vite build",
    "test": "vitest run"
  }
}

Углубление (2-3 минуты)​

  1. Свяжите тему "Какие anti-patterns бывают в конфигурации bundler?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Покажите, как решение сокращает lead time или снижает change failure rate.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Игнорируют flaky-тесты, из-за чего quality signal теряет доверие.
  2. Добавляют проверки в CI без учета времени обратной связи команды.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Как измерите влияние изменения на lead time и CFR?
  2. Какие quality gates обязательны перед релизом этой зоны?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. План rollout/rollback и критерии остановки релиза.
  2. Метрики процесса: lead time, CFR, flaky rate.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Package Managers и Bundlers
  2. Обучение: Tooling и Delivery
  3. Карта подготовки: Package Managers

20. Как строить миграцию Webpack -> Vite без остановки разработки?​

Теги: tooling, build, bundlers Сложность: Middle/Senior

Короткий ответ​

Миграция Webpack -> Vite делается поэтапно с проверкой build parity и метрик.

Что сказать на интервью (30-60 секунд)​

  1. Где это применяется: Критично для стабильного CI/CD, предсказуемых релизов и контролируемого размера бандла.
  2. Главный риск: Big-bang миграции без rollback-плана часто приводят к длительным инцидентам.
  3. Как проверяете решение: Сравниваю lead time и change failure rate до/после изменения процесса и фиксирую результат в runbook.

Мини-пример​

// package.json
{
  "scripts": {
    "build": "vite build",
    "test": "vitest run"
  }
}

Куда дальше​

  1. Вернитесь в модуль: Package Managers и Bundlers.
  2. Сверьтесь с картой темы: Package Managers.
  3. Продолжайте по маршруту: Middle трек.
  4. Закрепите один ответ на практике в Песочнице.

Углубление (2-3 минуты)​

  1. Свяжите тему "Как строить миграцию Webpack -> Vite без остановки разработки?" с одним production-сценарием и объясните, почему она влияет на результат.
  2. Привяжите тему к delivery-риску: что ломается в CI/CD без этого решения.
  3. Сформулируйте ключевой trade-off и объясните, как решение масштабируется на уровне системы.

Типичные ошибки​

  1. Добавляют проверки в CI без учета времени обратной связи команды.
  2. Деплоят без заранее описанного rollback-плана.
  3. Путают соседние концепции и не обозначают границы применимости выбранного подхода.

Follow-up вопросы​

  1. Какие quality gates обязательны перед релизом этой зоны?
  2. Как измерите влияние изменения на lead time и CFR?
  3. Какой trade-off на уровне архитектуры здесь самый критичный?

Что повторить​

  1. Структуру CI/CD и обязательные quality gates.
  2. План rollout/rollback и критерии остановки релиза.
  3. Пройдите 2-3 связных вопроса в Банке вопросов и проверьте устойчивость ответа.

Связанные модули и карта​

  1. Обучение: Package Managers и Bundlers
  2. Обучение: Tooling и Delivery
  3. Карта подготовки: Package Managers