tgoop.com/super_oleg_dev/183
Last Update:
Привет!
Свежий кейс отладки, вряд ли будет полезен (специфичный), но хочется его проговорить и забыть.
В Tramvai есть своя реализация микрофронтов с поддержкой Module Federation - Child Apps.
Какое-то время назад добавлял для Child Apps поддержку разделения на страницы для разных роутов, значительная часть работы заключалась в интеграции @loadable.
Так как микрофронты универсальные - используются на сервере и на клиенте, для эффективного добавления всех JS и CSS файлов на страницу при серверном рендеринге, нужно иметь список этих файлов.
Для этого мы уже использовали Module Federation ChunkCorrelationPlugin, который генерирует специальный json файл, содержащий список shared чанков, необходимых для микрофронта. Это как бы stats, но не тот stats что используется в webpack.
При использовании @loadable, нам нужно также иметь информацию о созданных через динамический импорт чанков, которую ChunkCorrelationPlugin не предоставляет.
Решил эту проблему через генерацию дополнительного stats_loadable.json файла с помощью плагина @loadable/webpack-plugin. На сервере не проблема запросить доп. файл для каждого микрофронта, так как мы кэшируем эти запросы.
Но можно и заморочиться и через кастомный плагин самостоятельно сгенерировать единый файл, который будет содержать информацию из обоих миров.
Итак (это еще присказка), добавили @loadable и динамические чанки для отдельных страниц, но получили дублирование общего кода в каждом чанке - так как при использовании Module Federation как правило отключают splitChunks, и генерируются конкретные файлы:
- точка входа в микрофронт (в нашем случае серверная и клиентская)
- сам код микрофронта
- чанки для shared зависимостей
На самом деле добавить splitChunks оказалось можно, главное аккуратно - все shared зависимости, указанные для Module Federation, должны быть исключены из группы, в которую попадут общие модули между страницами, разделенными через @loadable - по сути все модули которые тянут async чанки.
И сам конфиг splitChunks (использует подход granular chunking)
Итак, вернемся к отладке и непосредственно багу.
У нас есть матрица тестов Child Apps для проверки совместимости разных мажорных версий хостового приложения и микрофронтов.
Что бы тестировать один и тот же код приложения и микрофронтов, используем симлинки.
По не понятной до сих пор причине один тест начал падать, и показывать какие-то странные новые чанки, собранные для конкретного микрофронта, с названием содержащим webpack_sharing_consume.
Для сборки приложения и микрофронта через @tramvai/cli можно указать параметр "resolveSymlinks: false", который прокинет соответствующее значение в конфиг вебпака - и он как раз использовался в интеграционных тестах.
Также симлинки использует yarn workspaces, через который организована работа с пакетами фреймворка в нашей монорепе.
Отладку мне сильно попортили наши настройки webpack file-system cache, которые не учитывали этот параметр, и переиспользовался кэш с любым значением флага, а я соответственно получал не стабильные результаты.
Оказалось, что для получения списка shared модулей использовался require.resolve, который симлинки всегда резолвит, и отдает реальный путь. Пример - tramvai/packages/modules/react-query/lib/index.js
А в splitChunks в метод проверки вхождения в группу в название модуля прилетал путь симлинки которую делал yarn (с node_modules). Пример - tramvai/node_modules/@tramvai/module-react-query/lib/index.js
Дополнительно заиспользовал пакет resolve для вычисления пути до модуля без резолва симлинки, что бы закрыть и кейсы пользователей, и в нашей монорепе.
История получилась в итоге не совсем про отладку, но раз с этого начал, добавлю вывод - при отладке сборки выключайте кэши)
BY SuperOleg dev notes
Share with your friend now:
tgoop.com/super_oleg_dev/183