Блог

Этапы рассмотрения дела:

1. У меня есть packages/common packages/react-A эти 2 подпроекта внутри packages
2. react-A имеет зависимость common@1.0.0
3. Я обновился common с версии v1.0.0 до версии v2.0.0 и многое изменил.
4. В react-A нем будут отображаться ошибки, потому что его зависимость тоже будет обновляться.

Каждый раз, когда я обновляю свою common библиотеку для серьезных изменений, мне приходится исправлять другое место, где она зависит, это нормально?

TL;DR — да, изменение видимого кода / API общей зависимости, которая является общей для многих, заставит вас соответствовать этим изменениям в разных проектах. Это ожидаемо.

Что такое монорельсовый рабочий поток?

Monorepo-это хранилище кода с управлением версиями, в котором хранится множество проектов. Хотя эти проекты могут быть взаимосвязаны, они часто логически независимы и управляются разными командами.

Рабочий процесс включает (но не ограничивается) такими вещами, как:

• Крупномасштабные коммиты — коммиты, которые могут или не могут повлиять на несколько отдельных проектов одновременно.
• Видимость кода — проекты см. код других проектов.
• Общая история фиксаций — фиксации, которые затрагивают более одного проекта, должны быть видны.

и многое другое. Следовательно, рабочий процесс заключается в управлении несколькими проектами в рамках одного дерева истории. Как вы это делаете, зависит от команды…

Я думаю, что есть отличные онлайн-ресурсы и сообщения в блогах, которые очень подробно описывают, что такое монорепо, поэтому я не буду вдаваться в это, так как не думаю, что в этом суть вопроса. Есть ли у вас монорельс или только один проект с парой подмодулей в нем, решать вам, поскольку монорельс-это скорее концепция, чем реальная физическая вещь (я здесь довольно легкомысленно отношусь к определению).

Но я думаю, что ваш вопрос меньше связан с рабочим процессом monorepo и больше связан с общим дизайном программного обеспечения.

У вас есть common библиотека. Эта библиотека может иметь или не иметь API, который будут использовать другие. Этот API этой библиотеки может меняться или не меняться со временем. Если вы контролируете, как меняется этот API, то более чем очевидно, что если вы измените API, все, кто интегрируется с этой библиотекой, должны будут соответствовать новому API.

Если v1 у of common есть набор определенных сигнатур методов, которые определяют, как работает API, и v2 common изменяют эти сигнатуры, то пользователи, переходящие из v1 to, v2 должны изменить способ их использования common . По сути, это ничем не отличается от внутреннего рефакторинга кода или просто изменения функций для вашего собственного проекта. Теперь, если такой подход вам не по душе, и вы хотите иметь обратную совместимость и стабильный API, то есть конкретные методы разработки программного обеспечения для обеспечения стабильности и гибкости, но, скорее всего, это усилия, которые были вложены, так что внедрение изменения не затрагивают вам API, который затем влияет/не влияет на другие проекты.