1. Введение

Статьи, которые я прочитал на этой неделе,The many Benefits of Using a Monorepo.

Сейчас есть много статей, представляющих Monorepo, которые можно разделить на следующие категории: Непосредственное введениеLernaAPI; описывает, как перейти из автономного репозитория в Lerna; иллюстрирует важность Monorepo на примерах.

Эта статья относится к третьей категории, иллюстрирующей важность Monorepo из истории разработки Android и IOS.

Причина, по которой автор выбирает эту статью, не в том, что история хорошо написана, а в том, что она признает это универсальное решение. Ведь Lerna, как одна из реализаций Monorepo, не идеальна, и разные сценарии зависят от Monorepo по разным причинам и функциям, поэтому я надеюсь использовать эту статью, чтобы теоретически объяснить, почему генерируется Monorepo и какие проблемы может решить Monorepo. , чтобы при возникновении проблем на работе вы могли понять, чего хотите.

2. Обзор

Одним из проектов автора является PDF-сервис, именуемый PSPDFKit, который должен учитывать как платформы Android, так и IOS.Развитие проекта прошло следующие этапы.

Начальная фаза

В период с 2011 по 2013 год PSPDFKit поддерживал только платформу IOS, но окончательный проект должен был поддерживать Android, поэтому был открыт новый репозиторий для размещения кода Android. Код репозитория Android отличается не только пользовательским интерфейсом, но и основным кодом для анализа PDF-документов, потому что встроенный механизм рендеринга PDF используется на платформе IOS для одновременного расширения бизнеса, но используемый код OC нельзя использовать в Android.

В конце концов построили два складаPSPDFKit-Androidа такжеCore.

Код в Ядре склада опирается на поддержку платформы Android JNI, поэтому невозможно реализовать пожелание, чтобы одна модификация Ядра действовала в обоих местах, и мы надеемся, что функции обеих сторон всегда будут совместимы. , а потенциальные конфликты, вызванные слишком большим количеством веток, уменьшаются.Потребовалось много времени, чтобы понять, что два репозитория должны быть объединены.

Рассмотрите возможность использования монорепо

Так как весь процесс Android контролируется сам собой, всегда есть возможность быстро исправить ошибки, предложенные пользователями, однако CGPDF, предоставляемый IOS, всегда будет сталкиваться с различными проблемами. Итак, в 2014 году мы начали масштабный проект по переписыванию библиотеки Core для IOS. Есть три способа выбора:

1. Ссылка в коде IOSPSPDFKit-Android.
2. БудуPSPDFKit-Androidизвлечь вCoreсклад и поддерживается отдельно.
3. Объедините код IOS и Android в один репозиторий.

После обсуждения команда авторов наконец выбрала третий вариант, поэтому структура каталогов аналогична следующей:

- ios-platform
- android-platform
- core

особый случай

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

Только год спустя, когда мы начали изучать WebAssembly, появился модуль PSPDFKit-web, потому что WebAssembly можно использовать для компиляции кода Core и использования его на веб-платформе, поэтому связь между репозиторием Core и веб-платформой репозиторий стал очень тесным, и, наконец, Web и Server также были перенесены в Monorepo.

вопрос

Недостатки Monorepo не скрывают его недостатков, но автор все же перечисляет некоторые недостатки.

Поскольку исходный код находится в одном месте, изменения репозитория происходят очень часто, пространство для хранения становится большим, даже несколько ГБ, а время выполнения тестов CI увеличивается. Тем не менее, никто в команде не хочет возвращаться к мультирепозиторию подмодулей git.

3. Интенсивное чтение

В основном,Хотя разделение подрепозиториев и подпакетов NPM (для Интернета) является естественным решением для изоляции проекта, когда содержимое репозитория связано, нет более эффективного метода отладки, чем объединение исходного кода.

Конечная цель проектирования — позволить развитию бизнеса на 100 % сосредоточиться на бизнес-логике., то это не просто проблема, которую должны решать леса и каркасы с точки зрения автоматизации и проектирования, она включает в себя проектирование управления складом.

Идеальную среду разработки можно представить следующим образом:

«Заботьтесь только о бизнес-коде, вы можете напрямую повторно использовать его в бизнесе, не заботясь о методе повторного использования, и весь код находится в исходном коде при отладке».

В среде разработки интерфейса несколько Git Repo и несколько Npm являются идеальными сопротивлениями, что приводит к необходимости заботиться о номере версии для повторного использования и Npm Link для отладки.

Кроме того, к недостаткам многоскладского хозяйства можно отнести не упомянутые в статье некоторые факторы, которые перечислены здесь:

Сложность в управлении и отладке

Несколько репозиториев git по своей сути громоздки в управлении. Для модулей с похожими функциями, если они разделены на несколько хранилищ, необходимо открыть несколько страниц хранилища для совместной работы нескольких человек или независимой разработки.

Хотя vscode проходитWorkspacesРешите проблему управления несколькими складами, но в сценарии совместной работы нескольких человек невозможно обеспечить согласованность конфигурации среды для всех.

Для общих пакетов, установленных через Npm, если отладка скомпилированного кода неприемлема или каждый раз, когда щелкается ссылка npm, отладка зависимых подпакетов невозможна.

Путаница в управлении филиалом

Если склад предоставляется для двух проектов, А и Б, и проект Б сначала развивает функцию б и не может быть совместим с проектом А, то склад должен быть открыт на этом складе.feature/bветка поддерживает эту функцию и в будущем будет объединена с транком, синхронизированным с проектом A.

Как только компоненты, которые необходимо открыть, сложность управления ветвями возрастет в индексе.

сложные зависимости

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

Версии сторонних зависимостей могут быть несовместимыми

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

Занимает много места

В нормальных условиях бизнес-проект компании имеет только одну основу, а метод репозитория с несколькими git тратит впустую много места для хранения.Повторная установка больших модулей, таких как React, может со временем занять десятки ГБ дополнительного пространства.Для студентов, которые не иметь внешних жестких дисков. Например, регулярно убирать неиспользуемые элементы подnode_modulesТоже хлопот.

Не подходит для командной работы

В большом проекте могут использоваться сотни сторонних пакетов.Разные сторонние пакеты имеют разную частоту обслуживания, разные разрешения и разные местоположения склада.Основной склад зависит от них по-разному.

Как только один из пакетов внесет нештатное изменение, это повлияет на весь проект, а наши силы ограничены, мы фокусируемся только на основном складе, и часто попадаем в незаметный выпуск сторонних пакетов.

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

Идеальный дизайн монорепозитория

Ссылаться наLernaспецификация дляpackagesВ качестве корневой папки подмодуля автор разработал идеальную структуру монорепозитория:

.
├── packages
│      ├─ module-a
│      │    ├─ src            # 模块 a 的源码
│      │    └─ package.json   # 自动生成的，仅模块 a 的依赖
│      └─ module-b
│           ├─ src            # 模块 b 的源码
│           └─ package.json   # 自动生成的，仅模块 b 的依赖
├── tsconfig.json             # 配置文件，对整个项目生效
├── .eslintrc                 # 配置文件，对整个项目生效
├── node_modules              # 整个项目只有一个外层 node_modules
└── package.json              # 包含整个项目所有依赖

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

Между родственными модулями через модулиpackage.jsonОпределенныйnameСсылайтесь друг на друга, чтобы обеспечить независимость между модулями, но не нужно фактически публиковать или устанавливать этот модуль, черезtsconfig.jsonизpathsа такжеwebpackизaliasВместе для достижения эффекта пути виртуального модуля.

рекомбинацияLernaВ соответствии с функцией освобождения связи каждый подмодуль может быть освобожден независимо.

4. Резюме

LernaЭто самый известный в отрасли инструмент управления Monorepo с полным набором функций. Однако из-за очень высоких требований к универсальности необходимо поддерживать совмещение Monorepo между любыми проектами, поэтому вpackagesФайлы конфигурации в папке по-прежнему согласуются с независимым хранилищем, что вызовет проблему усечения конфигурации в среде TS. В то же время ссылки между пакетами также осуществляются через более общийsymlinkГотово, это приводит к тому, что все еще необходимо существовать в каталоге подмодуля.node_modulesпапку, и эффект зависит от команды инициализации проекта.

Если вы добавите некоторые уточнения, такие как Monorepo на основе среды Webpack + Typescript, вы сможете изменить набор идей и использовать функции времени выполнения этих инструментов, чтобы уменьшить количество кода шаблона или файлов конфигурации, а также еще больше улучшить эффект Monorepo.

Для сопоставления псевдонимов даsymlinkа такжеaliasсравнение:

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

Видно, что если билдер квалифицирован, карту псевдонимов можно сделать светлее и ее не нужно инициализировать.

Вопрос сегодня в том, нужно ли вашему проекту использовать Monorepo? Есть ли у вас другие требования для Monorepo?

Адрес обсуждения:Интенсивное чтение «Преимущество монорепо» · Выпуск №151 · dt-fe/weekly

Если вы хотите принять участие в обсуждении, пожалуйста,кликните сюда, с новыми темами каждую неделю, выходящими по выходным или понедельникам. Интерфейс интенсивного чтения — поможет вам отфильтровать надежный контент.

Сфокусируйся наАккаунт WeChat для интенсивного чтения в интерфейсе

special Sponsors

• Платформа полного процесса DevOps

Заявление об авторских правах: Бесплатная перепечатка - некоммерческая - не производная - сохранить авторство (Лицензия Creative Commons 3.0)