Отдельные фичи вынесены в пакеты или это микрофронтенды
Что проверяют
Различаете ли вы модульность на сборке и независимость в рантайме. Слова похожие, а следствия разные, и интервьюер смотрит, назовёте ли вы признак, по которому одно отличается от другого, или ответите модным термином.
Как отвечать
Дайте разделяющий критерий сразу: может ли команда выложить свою часть, не пересобирая и не выкатывая остальное приложение. Если нет, это пакеты, как бы они ни назывались.
- пакеты в монорепозитории: рабочие пространства npm, сборка одна, версия React одна, изменение приезжает обычным вливанием в общий репозиторий, ошибки контракта ловит компилятор;
- микрофронтенды: отдельная сборка, отдельная выкладка, соединение через федерацию модулей, импортные карты или веб-компоненты. Контракт становится рантаймовым, и ломается он уже у пользователя.
Скажите про цену. Общие зависимости надо объявлять одиночными, иначе в бандл приедут две копии React и сломаются хуки. Версии библиотек в разных приложениях расходятся, стили протекают, общее состояние и роутинг проектируются отдельно, отладка идёт сразу по двум сборкам.
Вывод, который хотят услышать: микрофронтенды решают организационную задачу, а не техническую. Они оправданы, когда несколько команд с разными релизными циклами мешают друг другу в одном конвейере. Для одной команды это накладные расходы без выигрыша, и нормальный ответ звучит как «у нас пакеты, и этого хватает».
Где спотыкаются
Называют микрофронтендами разбиение на папки по фичам. Если всё собирается одной командой сборки и выкатывается одним артефактом, независимости нет, есть структура каталогов.
Рассказывают только про плюсы. Про дублирование зависимостей, расхождение версий и двойную отладку не упоминают, и становится ясно, что подход знаком по статьям, а не по эксплуатации.
Выбирают по моде. Ответ «микрофронтенды современнее» без привязки к числу команд и релизным циклам показывает, что решение принималось не от задачи.