Если монорепа, можно в ts config указать "module_name/path": "path_to_component"
Если несколько разных реп, то либо в ядре надо руками прописывать declare "module_name" {}, либо в самом модуле надо при сборке генерировать типы и упаковывать в либу, после чего в ядре тянуть их как dev deps. Других вариантов не существует. Сначала я думал, что это очень плохо, что мы не знаем тип компонента и его пропсы, но позже я пришел к мысли, что оно и не нужно, потому что в идеале не должно быть никаких параметров. Типа куском модуль подцепляем и всё, делая его максимально независимым.
Тоже разбирался с микрофронтами и module federation. Была задача сделать загрузку микрофронтов таким образом, чтобы не приходилось ничего хардкодить. При твоём подходе на самом деле нет особой разницы между статикой и динамикой, потому что всё упирается в то, что список микрофронтов и ссылки на их remoteEntry зашиты в вебпак конфиге, из-за чего без новой сборки и нового деплоя ядра системы выкатить новый модуль не получится.
Там описано использование либы \@angular-architects/module-federation. Это комплексная библиотека, из которой нужна только одна из ее зависимостей - \@angular-architects/module-federation-runtime. В ней вполне себе фреймворконезависимый код, который предоставляет возможность контролировать загрузку модулей прямо из кода ядра системы, а не из конфига вебпака. Если смущает \@angular-architects в то время, когда используется, скажем, React, всегда можно сделать свою внутреннюю библиотеку:D В итоге задача сводится к написанию функции, которая на вход получает конфиг со списком модулей (это может быть json-файлик, какой-то бэкенд метод) и возвращает тебе модули, загруженные функцией loadRemoteModule. Я поэкспериментировал с React, всё работает как часы.
Надеюсь, будет полезно, много шишек набил на этой федерации модулей)
P.S. жаль пока нет адекватного способа завести MF на SSR.
Если монорепа, можно в ts config указать "module_name/path": "path_to_component"
Если несколько разных реп, то либо в ядре надо руками прописывать declare "module_name" {}, либо в самом модуле надо при сборке генерировать типы и упаковывать в либу, после чего в ядре тянуть их как dev deps. Других вариантов не существует. Сначала я думал, что это очень плохо, что мы не знаем тип компонента и его пропсы, но позже я пришел к мысли, что оно и не нужно, потому что в идеале не должно быть никаких параметров. Типа куском модуль подцепляем и всё, делая его максимально независимым.
Спасибо за статью!
Тоже разбирался с микрофронтами и module federation. Была задача сделать загрузку микрофронтов таким образом, чтобы не приходилось ничего хардкодить. При твоём подходе на самом деле нет особой разницы между статикой и динамикой, потому что всё упирается в то, что список микрофронтов и ссылки на их remoteEntry зашиты в вебпак конфиге, из-за чего без новой сборки и нового деплоя ядра системы выкатить новый модуль не получится.
Я нашел такую статью по использованию федерации модулей в angular: https://www.angulararchitects.io/en/aktuelles/dynamic-module-federation-with-angular/
Там описано использование либы \@angular-architects/module-federation. Это комплексная библиотека, из которой нужна только одна из ее зависимостей - \@angular-architects/module-federation-runtime. В ней вполне себе фреймворконезависимый код, который предоставляет возможность контролировать загрузку модулей прямо из кода ядра системы, а не из конфига вебпака. Если смущает \@angular-architects в то время, когда используется, скажем, React, всегда можно сделать свою внутреннюю библиотеку:D В итоге задача сводится к написанию функции, которая на вход получает конфиг со списком модулей (это может быть json-файлик, какой-то бэкенд метод) и возвращает тебе модули, загруженные функцией loadRemoteModule. Я поэкспериментировал с React, всё работает как часы.
Надеюсь, будет полезно, много шишек набил на этой федерации модулей)
P.S. жаль пока нет адекватного способа завести MF на SSR.