Заинтересовал config в ваше примере, о нем нет никакой информации. Может именно там есть что-то, что поможет мне :) Да и было бы интересно посмотреть на вашу демку
Как я понял, все модули лежат в одном репозитории и ревью / мерджи производятся в одном потоке с соответствующим пересечением в релизных циклах? Или для каждого модуля-папки заведет отдельный гит-репозиторий, просто получается в одной папке можно собрать сразу много репозиториев через cli-инструмент, который подтягивает версии?
Модули могут, нет, модули должны лежать в разных репозиториях! Соответственно для каждого из микрофронтендов может быть свой релизный цикл, свой CI/CD, свои стенды, своё тестирование и т. д. Самое главное — не нарушать контракт между микрофронтендами.
Так же, как вижу, в каждом из модулей могут использоваться разные версии npm-зависимостей, что приводит к рассинхрону и потенциальным багам, часть из которых описана в статье. Вскоре может понадобиться изменить конфиги вебпака для отдельного модуля — добавить другие лоадеры, плагины, сборку других фреймворков и т.п., но, как я понял, Module Federation опирается на единый конфиг. Как планируется разруливать этот кейс?
В Module Federation есть механизм, который резолвит версии пакетов опираясь на semver. Webpack-конфиги у разных микрофронтендов свои, так что можно использовать любые лоадеры и плагины и фреймворки, теоретически, можно подружить React, Vue и Angular, если немного полколдовать с вставкой микрофронтенда на страницу, я как раз собираюсь это попробовать.
И по поводу «разделения зоны ответственности» непонятно, чем данная схема лучше монолита — если код разбит на асинхронно загружаемые модули, то команды, их разрабатывающие, и так не будут пересекаться по коду. Проблема только в том, что используется один гит-репозиторий, но если команд не больше 4, разруливается менеджерингом лейблов и веток — в одном проекте так делали, пересечений фактически не было.
Да, мы тоже рассматривали такой вариант, но подход с Module Federation оказался более привлекательным с точки зрения независимого развертывания, ведь мы не завязаны на релизный цикл монолитного проекта. В перспективе, команд у нас будет больше 4, так что тут Module Federation нас выручит.
В монолите, к сожалению, тоже есть одна существенная проблема — так как собирается все и сразу, то время сборки значительно увеличивается (хотя есть несколько стратегий для динамического билдинга), при Module Federation, как понимаю, будут собираться только переданные через cli модули или тоже все?
При Module Federation мы можем параллельно запустить сборку нескольких микрофронтендов, и это будет быстрее, если бы мы собирали монолит.
как раз-таки получится, если говорить просто, то это обычный динамический импорт скрипта лежащего на другом хосте, то есть можно делать всё, что позволяет ваше воображение и технологии, которые вы используете
оба конфига лежат тут github.com/oceanEcho/examples/tree/master/module-federation
можно склонировать репозиторий и посмотреть как работает, если будут конкретные вопросы, то пишите, постараюсь ответить
Модули могут, нет, модули должны лежать в разных репозиториях! Соответственно для каждого из микрофронтендов может быть свой релизный цикл, свой CI/CD, свои стенды, своё тестирование и т. д. Самое главное — не нарушать контракт между микрофронтендами.
В Module Federation есть механизм, который резолвит версии пакетов опираясь на semver. Webpack-конфиги у разных микрофронтендов свои, так что можно использовать любые лоадеры и плагины и фреймворки, теоретически, можно подружить React, Vue и Angular, если немного полколдовать с вставкой микрофронтенда на страницу, я как раз собираюсь это попробовать.
Да, мы тоже рассматривали такой вариант, но подход с Module Federation оказался более привлекательным с точки зрения независимого развертывания, ведь мы не завязаны на релизный цикл монолитного проекта. В перспективе, команд у нас будет больше 4, так что тут Module Federation нас выручит.
При Module Federation мы можем параллельно запустить сборку нескольких микрофронтендов, и это будет быстрее, если бы мы собирали монолит.
и не только скрипт, на самом деле, всё, что может собрать вебпак
как раз-таки получится, если говорить просто, то это обычный динамический импорт скрипта лежащего на другом хосте, то есть можно делать всё, что позволяет ваше воображение и технологии, которые вы используете
в 5 вебпаке из коробки есть возможность пилить микрофронтенды — https://webpack.js.org/concepts/module-federation/
мы это уже используем в продакшене, если интересно, могу написать статью с гайдом, подводными камнями и т. д.