Все в одном: монорепозиторий на уровне проекта политики передового опыта

0. 🧉 Предисловие

В недавней разработке проекта возникла ситуация, которая меня обеспокоила. Разрабатываемый ИИ проект зависит от проекта Б, который был опубликован в сети, но в связи с непрерывным развитием проекта А мне необходимо время от времени изменять код проекта Б (эти модификации не нужно публиковать в сети для время),Как я могу синхронизировать изменения в проекте А во времени после изменения кода проекта Б?После того, как Project A будет опубликован в сети,Как элегантно решить проблему синхронизации версий после обновления версии проекта A, B?После некоторых исследований я обнаружил, что лучшим решением этих проблем является стратегия монорепозитория, описанная в этой статье.

1. 🤔 Что такое стратегия монорепо?

монорепозиторий — этоСтратегия разработки программного обеспечения для хранения кода нескольких проектов в одном репозитории.(«моно» происходит от греческого μόνος, означающегоОдин, а «репо», очевидно, является сокращением от «репозиторий»). Помещение кода разных проектов в один и тот же репозиторий кода на первый взгляд может показаться странным, но на самом деле такой способ управления кодом имеет множество преимуществ, независимо от Интернет-компаний мирового уровня Google, Facebook и известного сообщества открытого исходного кода. Команда проекта Babel (на фото ниже) использует стратегию монорепозитория для управления своим кодом.

Babel использует стратегию монорепозитория для управления кодом.

Каковы преимущества использования стратегии монорепозитория для менеджеров кода и разработчиков программ?**Как мы можем попробовать применить стратегию монорепо на работе? ** Это именно то, что эта статья намерена исследовать. Я надеюсь, что благодаря моему введению вы сможете получить более полное представление о стратегии монорепозитория, а инструменты и идеи, представленные в статье, действительно помогут вам и вашей команде.

2. 🌗 Плюсы и минусы стратегии монорепо

Организовывая свой код с помощью стратегии монорепозитория, структура каталогов вашего репозитория будет выглядеть следующим образом:

.
├── lerna.json
├── package.json
└── packages/ # 这里将存放所有子 repo 目录
    ├── project_1/
    │   ├── index.js
    │   ├── node_modules/
    │   └── package.json
    ├── project_2/
    │   ├── index.js
    │   ├── node_module/
    │   └── package.json
    ...

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

2.1 Преимущества монорепозитория

Повторное использование кода будет очень простым: Поскольку весь код проекта установлен в репозитории кода, мы легко извлеките бизнес-компоненты или инструменты, совместно используемые каждым проектом, а также кодируемым в виде Teamscript, Lerna или других инструментов;
Управление зависимостями будет очень простым: Точно так же, поскольку ссылки между проектами находятся в одном и том же репозитории, мы можем легко отслеживать, какие другие проекты будут затронуты при изменении кода проекта. Используя некоторые инструменты, мы будем легко управлять зависимостями версий и автоматически обновлять номера версий;
Рефакторинг кода станет очень удобным: Подумайте о том, что мешает вам провести рефакторинг вашего кода, часто это происходит из-за «неопределенности», вы не уверены, что изменение в одном проекте является «фатальным» для других проектов, из-за страха перед неизвестным вы не будете этого делать. провести рефакторинг кода, что приведет к гниению всего кода проекта с угрожающей скоростью. Под руководством стратегии монорепозитория вы можете четко знать масштаб влияния вашего кода и проводить унифицированные тесты на затронутых проектах, что будет стимулировать вас к постоянной оптимизации кода;
Он продвигает открытую, прозрачную и общую организационную культуру, которая способствует росту разработчиков и улучшению качества кода.: в рамках стратегии монорепозитория каждому разработчику предлагается просматривать и изменять код других людей (до тех пор, пока это необходимо), и в то же время это также стимулирует чувство ответственности разработчика за поддержку кода и написание модульных тестов ( в конце концов, перед визитом друзей мы не обращаем внимания на то, какой беспорядок у нас дома), что создает добродетельный технический климат, который защищает качество кода во всей организации.

2.2 Недостатки монорепозитория

Управление разрешениями на уровне проекта становится очень сложным: Будь то Git или другие системы контроля версий, не существует удовлетворительного решения для поддержки управления разрешениями на уровне проекта в стратегии монорепозитория, а это означает, что проект отдела А трудно не увидеть разработчикам отделение Б. . (К счастью, мы можем практиковать стратегию монорепозитория на уровне «проекта», что является темой этой статьи, и мы уточним это позже);
Более высокие затраты на обучение новых сотрудников: В отличие от модели с одним репозиторием кода на проект, новичкам нужно только ознакомиться с логикой кода в конкретном репозитории кода. В рамках стратегии монорепозитория новичкам, возможно, придется потратить больше усилий, чтобы разобраться в общей логике между репозиториями кода. , Конечно, эти расходы могут быть решены с помощью новых документов, но поддержание актуальности документов требует дополнительных трудовых ресурсов;
Для стратегии монорепозитория на уровне компании требуется выделенная система VFS с поддержкой инструментов автоматического рефакторинга.: Представьте себе, как такая компания, как Google, хранит миллиард строк кода в одном репозитории? Как долго разработчики должны ждать каждого извлечения кода? Как внедрить управление разрешениями и гибкий релиз между кодом каждого проекта? Любая простая стратегия помноженная на достаточный масштаб масштаба сотворит чудо (к лучшему или к худшему), для МСБ если нет сильных человеческих ресурсов как гугл, фейсбук положить весь код проекта на один склад Вот это доброе пожелание может быть только воздушным замком.

2.3 Резюме: как выбрать?

Правильно, никогда не было «серебряной пули» в разработке программного обеспечения. Стратегия монорепозитория также не идеальна, и я на практике обнаружил, что для того, чтобы правильно реализовать ее в организации, требуются не только отличные навыки программирования и терпение.Расписание команды,групповая культураа такжеличное влияниеКонечный результат столкновения определяет, сможет ли идея наконец реализоваться.

Но не отчаивайтесь слишком рано, потому что, хотя трудно заставить организации вносить изменения и единообразно внедрять стратегию монорепозитория, это не означает, что нам нужно полностью попрощаться со стратегией монорепозитория (иначе моя статья должна закончиться здесь). мы также можемПрактикуйте стратегию монорепозитория на уровне «проекта»., то есть логически определить взаимосвязь между проектами и проектами, а затем интегрировать связанные проекты под один склад.Обычно связанных проектов у нас не слишком много, а значит, мы можем получить его бесплатно Все преимущества монорепозитория стратегия, а также возможность отказаться платить проценты от крупной архитектуры монорепозитория.

Остальная часть этой статьи представляет собой краткое изложение «практики работы с монорепозиториями на уровне проекта». помочь тебе.

3. 🧑🏻‍💻 практика работы с монорепозиторием

3.1 Закрытая среда: Вольта

Volta— это менеджер инструментов JavaScript, который позволяет нам легко блокировать версии node, npm и yarn в наших проектах. Вам просто нужно выполнить в корневом каталоге вашего проекта после установки Voltavolta pinкоманда, то независимо от того, какую версию узла или npm (yarn) вы используете в настоящее время, volta автоматически переключится на указанную вами версию.

Таким образом, помимо использования Docker и демонстрации заявленной в документации версии node и npm (yarn), у вас есть еще один мощный инструмент для блокировки вашей среды.

И по сравнению с nvm у Volta также есть привлекательная особенность: когда инструмент CLI вашего проекта несовместим с глобальным инструментом CLI, Volta может автоматически идентифицировать его в корневом каталоге проекта и переключиться на версию, указанную проектом, и все это Volta делает это молча, и разработчику не нужно ни о чем заботиться.

3.2 Повторное использование пакетов: рабочая область

После использования стратегии монорепо двумя самыми большими преимуществами являются:

Избегает повторной установки пакетов, что снижает использование дискового пространства и сокращает время сборки.;
Внутренний код может ссылаться друг на друга;

Оба эти преимущества могут быть достигнуты с помощью зрелого инструмента управления пакетами для фронтенд-разработки, то естьyarn(выше 1,0) илиnpm(7.0 и выше) через файл с именемworkspaces(⚠️ Обратите внимание, что npm, поддерживающий функцию рабочих пространств, по-прежнему не является LTS-версией).

Чтобы получить два преимущества, упомянутых ранее, вам нужно сделать три вещи в своем коде:

Настройте структуру каталогов, чтобы разместить связанные проекты в одном каталоге, рекомендуется называть их какpackages;
в корневом каталоге проектаpackage.jsonфайл, наборworkspacesАтрибут, значением атрибута является каталог, созданный ранее;
Точно так же вpackage.jsonфайл, наборprivateсобственностьtrue(Чтобы мы не опубликовали склад по ошибке);

После модификации каталог вашего проекта должен выглядеть так:

.
├── package.json
└── packages/
    ├── @mono/project_1/ # 推荐使用 `@<项目名>/<子项目名>` 的方式命名
    │   ├── index.js
    │   └── package.json
    └── @mono/project_2/
        ├── index.js
        └── package.json

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

Обратите внимание, что мы назвали подпроекты, унифицированные с@<repo_name>/В начале это лучшая практика сообщества, которая не только облегчает пользователям понимание архитектуры всего приложения, но и облегчает вам поиск необходимых подпроектов в проекте.

На данный момент мы завершили основную часть стратегии монорепозитория, которая проста, не так ли? Но, как гласит старая поговорка, «сто миль — это половина девяноста».

3.3 Унифицированная конфигурация: объединение похожих элементов — Eslint, Typescript и Babel

Вы должны согласиться с тем, что написание кода следует принципу DRY (сокращение от Don't Repeat Yourself). Затем, конечно, мы должны стараться избегать дублирования eslintrc, tsconfig и других файлов конфигурации в нескольких подпроектах. К счастью, Babel, Eslint и Typescript предоставляют функциональные возможности для уменьшения повторения.

3.3.1 TypeScript

мы можемpackagesразмещен в каталогеtsconfig.settting.jsonфайл и определить общую конфигурацию ts в файле, то в каждом подпроекте мы можем передатьextendsсвойств, ввести общую конфигурацию и установитьcompilerOptions.compositeценностьtrue, в идеале, в подпроектеtsconfigФайл должен содержать только следующее:

{
  "extends": "../tsconfig.setting.json", // 继承 packages 目录下通用配置
  "compilerOptions": {
    "composite": true, // 用于帮助 TypeScript 快速确定引用工程的输出文件位置
    "outDir": "dist",
    "rootDir": "src"
  },
  "include": ["src"]
}

3.3.2 Eslint

Для файлов конфигурации Eslint мы также можем сделать то же самое, поэтому определим подпроект.eslintrcсодержание документа:

{
  "extends": "../../.eslintrc", // 注意这里的不同
  "parserOptions": {
    "project": "tsconfig.json"
  }
}

Заметил, что для общей конфигурации eslint мы не помещаем ее вpackagesкаталог, но в корневом каталоге всего проекта, это делается, потому что некоторые плагины редактора будут искать только в корневом каталоге проекта.eslintrcфайл, поэтому, чтобы поддерживать хорошую «согласованность среды разработки» для нашего проекта, обязательно поместите общий файл конфигурации в корневой каталог проекта.

3.3.3 Babel

Файлы конфигурации Babel объединяются так же, как TypeScript, даже проще, нам нужно только.babelrcФайл объявляет это так:

{
  "extends": "../.babelrc"
}

Когда все на месте, каталог нашего проекта должен выглядеть примерно так:

.
├── package.json
├── .eslintrc
└── packages/
    │   ├── tsconfig.settings.json
    │   ├── .babelrc
    ├── @mono/project_1/
    │   ├── index.js
    │   ├── .eslintrc
    │   ├── .babelrc
    │   ├── tsconfig.json
    │   └── package.json
    └───@mono/project_2/
        ├── index.js
        ├── .eslintrc
        ├── .babelrc
        ├── tsconfig.json
        └── package.json

3.4 Унифицированный командный сценарий: scripty

На предыдущем шаге мы максимально абстрагировали все конфигурационные файлы, тем самым упростив код и улучшив согласованность всего проекта. Весь наш склад также имеет «более сильный аромат монорепозитория ☕️». Но если вы внимательно посмотрите на весь наш инженерный файл, там есть один очевидный недостаток и несколько раздражающих неприятных запахов, когда вы внимательно посмотрите на свои многочисленныеpackage.jsonфайл, вы знаете, о чем я говорю -- скрипты script.

Если у вас достаточно подпроектов, вы можете обнаружить, что каждыйpackage.jsonв файлеscriptsсвойства схожи, а некоторыеscriptsНаполнен различными синтаксисами Linux, такими как оператор канала, перенаправление или создание каталога.Повторение ведет к неэффективности, сложность ведет к непониманию, это проблемы, которые нам нужно решить.

Приведенное здесь решение заключается в использованииscriptyУправляйте своей командой скрипта просто, scripty позволяет вам определить команду скрипта в файле иpackage.jsonФайл ссылается непосредственно по имени файла. Это позволяет нам достичь следующего:

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

При использовании scripty для управления нашим приложением монорепозитория структура каталогов будет выглядеть следующим образом:

.
├── package.json
├── .eslintrc
├── scirpts/ # 这里存放所有的脚本
│   │   ├── packages/ # 包级别脚本
│   │   │   ├── build.sh
│   │   │   └── test.sh
│   └───└── workspaces/ # 全局脚本
│           ├── build.sh
│           └── test.sh
└── packages/
    │   ├── tsconfig.settings.json
    │   ├── .babelrc
    ├── @mono/project_1/
    │   ├── index.js
    │   ├── .eslintrc
    │   ├── .babelrc
    │   ├── tsconfig.json
    │   └── package.json
    └── @mono/project_2/
        ├── index.js
        ├── .eslintrc
        ├── .babelrc
        ├── tsconfig.json
        └── package.json

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

Используя сценарий, подпроектpackage.jsonв файлеscriptsСвойства будут очень оптимизированы:

{
  ...
  "scripts": {
    "test": "scripty",
    "lint": "scripty",
    "build": "scripty"
  },
  "scripty": {
    "path": "../../scripts/packages" // 注意这里我们指定了 scripty 的路径
  },
  ...
}

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

🧉 Советы:

Не забудьте использовать сценарии chmod -R u+x, чтобы сделать все сценарии оболочки исполняемыми, и не забудьте включить этот совет в свой файл README.md!

3.5 Единое управление пакетами: Лерна

Источник изображения: https://github.com/lerna/lerna

Иногда я чувствую, что мне не хватает вдохновения, как я могу не придумать такое хорошее имя, как Лерна, которое является одновременно мифическим и самоочевидным. Как вы можете себе представить, каждая голова Гидры помогает вам управлять подпроектом, и вам нужно только ездить на драконе, чтобы отдавать приказы, что в основном мы интуитивно чувствуем при использовании Lerna.

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

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

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

С помощью Lerna эти острые проблемы исчезнут.

При использовании в корневом каталоге проектаnpx lerna initПосле инициализации наш корневой каталог добавит новыйlerna.jsonфайл, содержимое по умолчанию:

{
  "packages": ["packages/*"],
  "version": "0.0.0"
}

Давайте немного изменим этот файл, чтобы он стал таким:

{
  "packages": ["packages/*"],
  "npmClient": "yarn",
  "version": "independent",
  "useWorkspaces": true,
}

Обратите внимание, что мы явно объявляем наш пакетный клиент (npmClient)дляyarn, и пусть Lerna отслеживает каталог с настройками наших рабочих пространств, поэтому мы по-прежнему сохраняем прежнийworkspacesвсе особенности(ссылка на подпроекта такжеУниверсальный пакет).

В дополнение к этому интересным изменением является то, что мы будемversionатрибут указан как ключевое словоindependent, который сообщит lerna, что он долженРассматривайте номер версии каждого подпроекта как независимый друг от друга. Когда код подпроекта обновится, запуститеlerna publish, Lerna будет отслеживать подпроекты с изменениями кода и позволит разработчику решить, какой номер версии необходимо обновить с помощью интерактивного интерфейса командной строки. Номер версии связанного подпроекта не будет обновляться автоматически. Наоборот, когда мы заполняем фиксированный номер версии. Изменение кода любого подпроекта приведет к обновлению номеров версий всех подпроектов на основе текущего указанного номера версии.

Lerna предоставляет множество команд CLI для удовлетворения различных потребностей, но, согласно правилу 2/8, в первую очередь следует сосредоточиться на этих командах:

lerna bootstrap: Эквивалентноlerna link + yarn install, используемый для создания совместимых ссылок и установки зависимых пакетов;
lerna run: будет выполнять сценарий сценария npm во всех подпроектах, таких как цикл for, и он будет очень разумно распознавать зависимости и выполнять команды из корневой зависимости;
lerna exec:картинаlerna runТо же самое, будет выполнять команды в порядке зависимостей, разница в том, что он может выполнять любую команду, например сценарий оболочки;
lerna publish: Публикуйте пакеты с изменениями кода, поэтому сначала вам нужно использовать Lerna, прежде чем использоватьgit commitКоманда для отправки кода, чтобы у Лерны была базовая линия;
lerna add: добавить локальный или удаленный пакет в качестве зависимости к текущему репозиторию монорепозитория.Эта команда позволяет Lerna идентифицировать и отслеживать зависимости между пакетами, поэтому это очень важно;

# 向 @mono/project2 和 @mono/project3 中添加 @mono/project1
lerna add @mono/project1 '@mono/project{2,3}'

3.5.1 Расширенные команды Lerna

В дополнение к общим командам, представленным выше, Lerna также предоставляет некоторые параметры для удовлетворения наших более гибких потребностей, таких как:

--concurrency <number>: параметр может заставить Lerna использовать несколько ядер на компьютере и работать одновременно, тем самым повышая скорость сборки;
--scope '@mono/{pkg1,pkg2}':--scopeПараметр может указать среду выполнения команды Lerna.При использовании этого параметра Lerna больше не будет выполнять команды на всех складах в шаттле, но может точно выполнять команды на указанном нами складе, а также поддерживает пример в синтаксисе шаблона;
--stream: этот параметр позволяет нам просматривать информацию о выполнении команды во время работы Lerna;

Пакет 3.5.2 npm выпущен локально: Verdaccio

Смотрите здесь, вы можете испытать ощущение личного использования проекта Lerna Management / Publish Monorepo. Но вскоре вы обнаружите, что хранилище NPM для публикации примеров кода в реальном мире — не очень хорошая идея, что несколько разочаровывает, но не волнуйтесь, вы можете использоватьVerdaccioСоздайте локальный репозиторий npm в качестве прокси и наслаждайтесь всеми возможностями Lerna.

Установить и запустить Verdaccio так же просто, как запустить:

npm install --global verdaccio

Установите приложение Verdaccio глобально, затем введите в оболочке:

verdaccio

может пройтиlocalhost:4837Посетите свой локальный репозиторий прокси npm, не забудьте создать его в корне вашего проекта..npmrcФайл и переписывайте адрес прокси в вашем локальном файле NPM Warehouse Address будет:

registry="http://localhost:4873/"

Готово 🙌! всякий раз, когда вы выполняетеlerna publish, пакет, созданный подпроектом, будет опубликован в локальном репозитории npm, а при выполненииlerna bootstrap, Verdaccio выпустит его, что позволит вам успешно извлечь соответствующий код из удаленного репозитория npm.

3.6 Форматирование информации о коммите

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

Монорепозиторий может бытьРазные разработчики представляют разные подпроектыЕсли нет нормализованной информации о коммите, не будет случайной аварии при устранении неполадок или откате версии. Поэтому не стоит недооценивать важность форматирования сообщения коммита (и, конечно же, комментариев кода!).

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

Как подсказывает название,commitlintЭто может помочь нам проверить отправленную информацию о коммите.Он обеспечивает, чтобы наша информация о коммите была добавлена с указанным типом в начале, который используется для обозначения общего намерения этой отправки.Ключевые слова поддерживаемого типа:

feat: указывает на добавление новой функции;
chore: Указывает, что была выполнена некоторая «домашняя работа», не связанная с функциями и ремонтом;
fix: Указывает, что ошибка исправлена;
refactor: указывает, что эта отправка связана с рефакторингом кода;
style: Указывает на улучшение или форматирование кода;
...

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

В дополнение к ограничению типа информации о коммите, commitlint также поддерживает (хотя это и не обязательно) явное указание имени подпроекта, соответствующего нашему текущему коммиту. Предположим, у нас есть@mono/project1Подпроект, информацию о коммите, которую мы отправляем для этого проекта, можно записать так:

git commit -m "feat(project1): add a attractive button" # 注意，我们省略了 @mono 的项目前缀

Без сомнения, это сделает наши сообщения коммитов более выразительными.

Мы можем установить его с помощью следующей командыcommitlintи окружающие зависимости:

npm i -D @commitlint/cli @commitlint/config-conventional @commitlint/config-lerna-scopes commitlint husky lerna-changelog

Ты заметил? я тайно установилhusky, что может помочь нам запускаться автоматически при отправке информации о коммитеcommitlintпроверить, но перед этим нам нужноpackage.jsonДобавьте содержимое в файл, например:

{
 ...
 "husky": {
    "hooks": {
      "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
    }
  }
 ...
}

чтобы позволитьcommitlintВосприняв название нашего подпроекта, нам также необходимо добавить его в корневую директорию проектаcommitlint.config.jsфайл и установите содержимое файла:

module.exports = {
  extends: [
    "@commitlint/config-conventional",
    "@commitlint/config-lerna-scopes",
  ],
};

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

(Кстати, это можно сделать в командной строке командойecho "build(project1): change something" | npx commitlintКоманда, чтобы проверить, проходит ли ваша информация о коммите проверку commitlint. )

4. 🚚 Как перейти со стратегии мультирепо на стратегию монорепо?

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

ты помнишь? Если у вас есть сто миль, у вас есть полдевяносто, и у вас еще есть несколько ям, на которые нужно наступить. Но, к счастью, вы все еще можете получить мою помощь здесь, пожалуйста!

Как вы могли заметить, Лерна предоставляет намlerna import чтобы импортировать наш существующий пакет в репозиторий монорепозитория, а также сохранить всю информацию о фиксации репозитория. Однако на практике эта команда поддерживает толькоимпортировать локальный проект,а такжене поддерживаетсяИмпортировать ветки и теги проекта 🙃.

Так что, если мы хотим импортировать удаленный репозиторий или получить ветку или тег? Ответ заключается в использованииtomono, содержимое которого представляет собой сценарий оболочки.

Чтобы импортировать удаленный репозиторий с помощью tomono, вам нужны всего две вещи:

Создайте текстовый файл, содержащий все адреса репо, которые необходимо импортировать;
Выполните команду оболочки:cat repos.txt | ~/tomono/tomono.sh(Здесь мы предполагаем, что ваш текстовый файл с именемrepos.txt, и вы загружаете tomono в корневой каталог пользователя;

Пример содержимого файла репо выглядит следующим образом:

// 1. Git仓库地址  2. 子项目名称  3. 迁移后的路径
git@github.com/backend.git @mono/backend packages/backend
git@github.com/frontend.git @mono/frontend packages/frontend
git@github.com/mobile.git @mono/mobile packages/mobile

На данный момент мы также освоили метод переноса существующих проектов в проекты монорепозитория. К этому времени вы уже не профан в мире монорепозиториев!

поздравляю! ! 🎉

5. 🎓 Резюме

В этой статье мы совместно узнали о «Что такое стратегия монорепо"так же как"Плюсы и минусы стратегии монорепо», и вместе изучите некоторые передовые практики для стратегий монорепозитория. Вы также должны понимать, что даже если ваша рабочая ситуация временно не позволяет практиковать стратегию монорепозитория, методы, инструменты и идеи, извлеченные из этой статьи, также могут быть применены к вашей текущей работе.

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

Что касается темы монорепозитория, я возьму вас пока исследовать здесь, и будет период :)

6. 📝 Ссылки

📹JavaScript and TypeScript Monorepos
📄Почему вам стоит использовать единый репозиторий для всех проектов вашей компании
📄Advantages of monorepos
📄Лучшие практики управления интерфейсными пакетами с помощью lerna
📄Рабочий процесс Monorepo на основе рабочего пространства lerna и yarn
📄Monorepos in the Wild
📄Монорепо: Пожалуйста, не надо!
📄Monorepo: please do!
📄Introduction to Lerna
📄практика миграции монорепо

7. 👀 Расширенное чтение

Внедрить практику экологии монорепозитория:awesome-monorepo
Документ о том, как Google организует миллиарды кода в монорепозитории:Why Google Stores Billions of Lines of Code in a Single Repository
Отчет об исследовании для Google, в котором подробно анализируются преимущества и недостатки монорепозитория:Advantages and Disadvantages of a Monolithic Repository

8. 🙌 Информация о наборе персонала

Команда по развитию пользователей отдела Alibaba TaoЯ с нетерпением ищу партнеров-единомышленников. Если вы готовы принять умеренный вызов, позволить большему количеству людей полюбить ручную покупку, и в то же время позволить себе быстро расти, вы можете отправить свое резюме на мой почтовый ящик:kongtang.lb@alibaba-inc.com, С нетерпением жду Вашего ответа.

Изображение на обложке предоставлено: Фото Татьяны ШИШКИНОЙ на Unsplash
Эта статья поддерживает только платную перепечатку, пожалуйста, свяжитесь с автором, чтобы обсудить стоимость перепечатки.