идеально

дизайн-ревью невозможно пройти, потому что дизайнеры будут каждый день ревьювить каждую правку компонента

вы уже пробовали юзать его?

пробовали
развалился на этапе сборки тс

не работает этот подход

сейчас работаем над тем, чтобы идти в другую сторону:
из дизайнов генерировать код/разметку

системность работает лучше разрозненности

хм, спасибо, учтем

а это как называется говнокодер только у дизайнеров? а то у меня подозрения что у нас такой

с чем мы столкнулись:
1. обновил компонент, разъехалась верстка остальных, а ещё получаешь варнинги несовпадения версий

2. куча разработчиков постоянно меняют компоненты под себя. Быстро появляется куча форков, под каждый новый проект, новый форк кнопки

3. невозможно сделать дизайн-систему. Поддерживать 50 компонентов, где у каждого несколько версий в проекте, крайне тяжело. Тестировать это крайне тяжело. Ведь приходится при обновлении компонента, проверять не только на последней версии всех компонентов, но и тестировать различные комбинации, а это дно, которое невозможно легко достать.

4. постоянно неактуальные компоненты в проектах. Мы выпустили обновления для компонентов. Но к нам приходят с проблемами: кнопка первой версии, а группировка кнопок уже третьей и вместе не работают, что делать. Обновить не могут, ибо завязаны на эту версию кнопки. Или не могут обновить, потому что где-то ещё поедет.

Бездарь

😅😅

кстати дельное замечание))

как решили:
1. Компоненты выпускаются пачками, и обновляются пачками. Тестируется полностью вся пачка компонентов. Дизайн-ревью проходит тоже разом вся пачка. Установить одну зависимость и обновлять её, гораздо легче, чем десятки.

2. Компоненты делятся на пачки по смыслу: core где лежат основные атомы и молекулы, timing всякие компоненты для работы с датами и временем, editor компоненты для richtext editor, banking всё для банка, карточки и акции. Эти пачки могут шариться между разными проектами.

3. У каждого проекта есть внутри своя библиотека компонентов, которая не является пакетом и не имеет своей версии. Но которая зависит от каких-то пачек.

4. Стараемся сводить количество пачек к минимуму. Чтобы не порождать проблемы зависимостей: чтобы получить новую банковскую карточку, нужно установить новый core, а это тянет за собой обновление внутренней библиотеки компонентов.

5. Тщательно следим за semver в пачках. Major release как можно реже. Собираем breaking в отдельном RFC и релизим много ломающих изменений разом. Поддерживаем только одну предыдущую версию.

6. При каждом релизе и дизайн-ревью генерируем карту состояний для каждого компонента, карту всех компонентов, также объединяем созданные компоненты в наборы, и запускаем в разных размерах экранов, для всего этого делается скриншот тесты через percy. То есть всегда четко видно, какие компоненты и где изменились. Аналогичная процедура есть для Props API каждого компонента. Генерируем автоматический diff для набора пропс каждого компонента и в релизе видно что изменилось.

Извиняюсь за оффтоп, кто нибудь из участников группы пользуется tailwind css?

Ооо круто

Подскажите пожалуйста как зафорить апдейт стора?

в какой ситуации возникла такая потребность?

ну там прикольно что можно не прыгая по репам прям сразу быстро взять и поправить пакет и выкатить новую версию