Полностью поддерживаю. Очень хорошее описание. Сталкивался с разными форматами и как раз формат 5-6 человек без модератора - идеальный формат. Мы на первое время принимали простое правило "во время дейли стоим". Это помогло очень быстро избавиться от обсуждений,которые не относились к дейли. Оказалось,что все очень даже умеют лаконично рассказывать о том,что делали.
Никто не мешает оставлять микрофронты в монорепе обособленными.
Плохо настроен запуск? Тут же вопрос скорее к людям.
Монорепа заставляет работать однотипно? А всегда ли это плохо?
В общем,сколько людей,столько и мнений.
P.S. Да,для микрофронтов идеальный вариант это жизнь в отдельных репах и использовать корректную настройку shared зависимостей,но это не всегда получается(как в вашем примере с запуском).
Могу поделиться своими наблюдениями про mfe и fsd.
mfe хороши, но не панацея. При использовании mfe сразу встаёт несколько вопросов:
1) Как поддерживать консистентность зависимостей? Для себя принял, что mfe хорошо дружат с nx. При использовании nx сразу упрощается управление зависимостями, деплой, запуск в dev режиме(запуск был актуальным вопросом т.к. количество mfe в проекте было более 20).
2) Шаринг зависимостей. Тут всё очень неоднозначно т.к. при шаринге какой-либо библиотеки мы сразу теряем treeshaking т.к. сборщик не может угадать какие части библиотеки понадобятся. Опять же, в данном случае мне помог nx с его упором на создание библиотек из коробки.
3) При работе с большим количеством mfe автоматически встаёт вопрос динамической подгрузки mfe. Если не решить данный вопрос, то вы автоматически будете дёргай тот самый злосчастный remoteEntry.js для каждого mfe.
Также хотел отметить, что автор плохо понимает что получает на выходе. Особенно это хорошо видно в следующем фрагменте:
"@uikit": "uikit@http://localhost:8081/remoteEntry.js",
"@api": "api@http://localhost:8082/remoteEntry.js",
Китовая библиотека компонентов и библиотека для общения с апи не являются самостоятельными единицами. Данные модули должны быть расшарены как общие зависимости через хост приложение.
Про fsd. Подход имеет место быть, но стоит держать в уме, что просто взять и перенести средний/большой проект на fsd не выйдет без специалиста, который хорошо знаком с данным подходом. Сталкивался с ситуацией когда на проекте fsd и всё круто, но в какой-то момент людям приходит понимание, что большая часть разработчиков распихивает код по слоям рандомно и проект превращается в кашу. Поэтому первое время потребуется строгое ревью.
Вы ссылку на самое важное потеряли
https://steroids.dev/ru/docs
На первом же скриншоте бросается в глаза:
1) Построение предложения странное;
2) Приведены не правила, а лишь указания на то,что было исправлено.
Полностью поддерживаю. Очень хорошее описание. Сталкивался с разными форматами и как раз формат 5-6 человек без модератора - идеальный формат. Мы на первое время принимали простое правило "во время дейли стоим". Это помогло очень быстро избавиться от обсуждений,которые не относились к дейли. Оказалось,что все очень даже умеют лаконично рассказывать о том,что делали.
Не,не один. Тоже с большой долей скепсиса отношусь к таким активностям.
Я тут недавно столкнулся с анонимным опросом,но для прохождения нужно пройти аутентификацию в корпоративной системе)
У монорепы есть минусы- не спорю с этим.
Никто не мешает оставлять микрофронты в монорепе обособленными.
Плохо настроен запуск? Тут же вопрос скорее к людям.
Монорепа заставляет работать однотипно? А всегда ли это плохо?
В общем,сколько людей,столько и мнений.
P.S. Да,для микрофронтов идеальный вариант это жизнь в отдельных репах и использовать корректную настройку shared зависимостей,но это не всегда получается(как в вашем примере с запуском).
mfe хороши, но не панацея. При использовании mfe сразу встаёт несколько вопросов:
1) Как поддерживать консистентность зависимостей? Для себя принял, что mfe хорошо дружат с nx. При использовании nx сразу упрощается управление зависимостями, деплой, запуск в dev режиме(запуск был актуальным вопросом т.к. количество mfe в проекте было более 20).
2) Шаринг зависимостей. Тут всё очень неоднозначно т.к. при шаринге какой-либо библиотеки мы сразу теряем treeshaking т.к. сборщик не может угадать какие части библиотеки понадобятся. Опять же, в данном случае мне помог nx с его упором на создание библиотек из коробки.
3) При работе с большим количеством mfe автоматически встаёт вопрос динамической подгрузки mfe. Если не решить данный вопрос, то вы автоматически будете дёргай тот самый злосчастный remoteEntry.js для каждого mfe.
Также хотел отметить, что автор плохо понимает что получает на выходе. Особенно это хорошо видно в следующем фрагменте:
"@uikit": "uikit@http://localhost:8081/remoteEntry.js","@api": "api@http://localhost:8082/remoteEntry.js",
Китовая библиотека компонентов и библиотека для общения с апи не являются самостоятельными единицами. Данные модули должны быть расшарены как общие зависимости через хост приложение.
Про fsd. Подход имеет место быть, но стоит держать в уме, что просто взять и перенести средний/большой проект на fsd не выйдет без специалиста, который хорошо знаком с данным подходом. Сталкивался с ситуацией когда на проекте fsd и всё круто, но в какой-то момент людям приходит понимание, что большая часть разработчиков распихивает код по слоям рандомно и проект превращается в кашу. Поэтому первое время потребуется строгое ревью.
Руслан, вы правы. Никому не хочется тащить кучу remoteEntry, которые могут и не пригодиться вовсе.
Ещё стоит отметить,что для angular из коробки доступна динамическая подгрузка mfe, а для react нет,но есть 2 варианта решения:
Использование готового решения на основе подхода для angular
Реализовать свой вариант. Тут будет полезно почитать доку Webpack по этой теме