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

В этой статье я расскажу о случае, с которым я столкнулся в реальной работе, от первоначального анализа требований до построения проекта и всего процесса окончательной реализации архитектуры. Конечным эффектом является использованиеmono-repoРеализовано совместное использование компонентов между проектами. В этой статье вы можете увидеть:

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

Шаблон архитектуры, созданный в этой статье, был загружен на GitHub, Если вам просто нужен шаблон mono-repo + react, просто клонируйте его:GitHub.com/Денис — см....

нужно

Обзор спроса

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

Это изображение банка, которое я нашел в Интернете, что-то похожее на наш сценарий использования. У него есть банкомат самообслуживания и прилавок с людьми на расстоянии. Также у нас будут автоматы самообслуживания, а также будут ручные счетчики.Оба места могут оплачивать коммунальные услуги,авто штрафы и т.д.С той лишь разницей,что помимо оплаты различных счетов,могут быть еще и какие-то продажи,такие как рот и рот.Когда я хочу пить, я покупаю кока-колу, а когда я пристрастился к курению, я покупаю китайский.

анализ спроса

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

Будь то оплата счетов или продажа кока-колы, мы можем рассматривать это как товар. Поскольку товары продаются, они должны иметь функцию размещения их на полках и с них, то есть управление товарами. Это должно выполняться только кассиром. сторона.
В мэрии много людей, а также будут отношения между начальством и подчиненными.У обычного кассира может не быть разрешения добавить/убрать полку.У него может быть только разрешение на продажу, а менеджеру может понадобиться управлять загрузкой/удалением, что означает, что интерфейс кассира также нуждается в управлении разрешениями.
Основой управления полномочиями должно быть управление пользователями, поэтому интерфейс кассира должен быть зарегистрирован и зарегистрирован.
Интерфейс самообслуживания клиента может только оплачивать счета и не может продавать кока-колу. Это легко понять, потому что это автомат самообслуживания, и там нет дежурных. Если есть несколько бутылок колы, он может взять Кокс и не платить.
Нужно ли клиентам входить в систему для самостоятельной оплаты счетов за воду и электричество? ненужный! Как и в Китае, вам нужно ввести только основную информацию, такую как номер карты и имя, чтобы проверить счет, а затем оплатить кредитной картой онлайн. Таким образом, клиентский интерфейс не требует входа в систему и управления пользователями.

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

Прототипирование

Основываясь на приведенном выше анализе, наши дизайнеры быстро создали прототипы двух интерфейсов.

Это интерфейс кассира:

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

Это интерфейс самообслуживания клиентов:

Это клиентский интерфейс выглядит в основном так же, но меньше, что пользователь и настроить и продавать вещи меньше колы, может только оплатить счет.

Технология

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

Один сайт или два сайта?

Прежде всего, нам необходимо рассмотреть вопрос: встроены ли интерфейс кассира и интерфейс клиента в один веб-сайт или это два отдельных веб-сайта? Поскольку два интерфейса очень похожи, мы можем сделать это вместе, просто спрятав пользователей и настройки в правом верхнем углу интерфейса самообслуживания клиентов.

Но на самом деле здесь скрыта проблема:Интерфейс кассира должен быть авторизован, поэтому его вход на самом деле является страницей входа; интерфейс клиента не нужно входить в систему, его вход должен быть непосредственно страницей продаж.. Если вы объедините их, потому что вы не знаете, используется ли он кассиром или покупателем, вход может быть только страницей входа. Кассир может войти непосредственно на страницу продаж. Для клиента вы можете добавить отдельный «вход в самообслуживание клиента», чтобы он мог войти на страницу продаж клиента. Но такПлохой пользовательский опыт, клиенту не нужно входить в систему, вы можете вызвать путаницу, если покажете ему страницу входа, вам может потребоваться часто спрашивать персонал, чтобы узнать, как ее использовать, что снизит общую эффективность работы, поэтому менеджер по продукту делает не принимает это и просит клиента зайти Вам нужно увидеть страницу продаж клиента.

А с технической точки зрения сейчас мыif...else...Просто скройте пользователя и настройки.В случае, если разница между двумя интерфейсами станет больше в будущем, и пользовательский интерфейс требует более причудливых эффектов, это не просто.if...else...Это может быть сделано.Итак, в итоге мы решили развернуть два сайта, интерфейс кассира и интерфейс клиента были развернуты отдельно на двух доменных именах..

дублирование компонентов

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

Будучи начинающим инженером, CV Dafa не может решить такие повторяющиеся компоненты, поэтому мы должны найти способ сделать эти компоненты многоразовыми. Как повторно использовать компоненты? Если говорить об общедоступной библиотеке компонентов, думаю, многие друзья подумают именно так. Мы тоже так думаем, но есть много способов организовать общедоступную библиотеку компонентов, и мы в основном рассматриваем следующие:

отдельные пакеты npm

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

import { Cart } from 'common-components';

Однако компоненты, которые нам нужно повторно использовать, такие же, как иantdКомпоненты имеют одно существенное отличие:Нам нужно повторно использовать бизнес-компоненты, а не чистые компоненты пользовательского интерфейса..antdВ целях обеспечения универсальности библиотека компонентов пользовательского интерфейса в основном не имеет бизнес-атрибутов, а стиль также открыт. Но мой бизнес-компонент здесь — это не просто несколько кнопок, несколько полей ввода, а полная форма, включая логику проверки интерфейса, которую нужно использовать повторно.Таким образом, компоненты, которые мне нужно повторно использовать, на самом деле тесно связаны с бизнесом.. Поскольку он сильно привязан к бизнесу, даже если я опубликую его отдельным пакетом NPM, другие проекты в компании не смогут его использовать. Пакет NPM, который нельзя использовать совместно с другими проектами, всегда кажется немного непоследовательным.

git submodule

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

По сутиsubmoduleи основной проект два разныхgit repo, поэтому вам нужно создать набор шаблонов (спецификации кода, сценарии выпуска и т. д.) для каждого проекта.
submoduleНа самом деле, только основной проект сохраняет ссылку зависимости на подпроект, указывая, от какой версии подпроекта зависит текущая версия основного проекта, пользоваться ею нужно осторожноgit submodule updateуправлять этой зависимостью. если не правильно использоватьgit submodule updateИ испортить зависимости от версии, вот и все. . .
При публикации необходимо аккуратно обращаться с зависимостями, сначала опубликовать подпроект, а затем опубликовать основной проект, когда подпроект будет готов.

mono-repo

mono-repoЭто метод управления проектами, который сейчас становится все более и более популярным, и его противоположность называетсяmulti-repo.multi-repoто есть多个仓库, вышесказанноеgit submoduleНа самом деле этоmulti-repoВ одну сторону, как основной, так и отдельный сабgit仓库, что также составляет多个仓库. а такжеmono-repoто есть一个大仓库, несколько элементов помещаются в一个git仓库в. Многие известные проекты с открытым исходным кодом сейчас используютmono-repoорганизации, напримерBabel,React ,Jest, create-react-app, react-routerи т.п.mono-repoЭто особенно подходит для нескольких тесно связанных проектов, таких как ситуация, с которой столкнулась эта статья.Теперь мы перейдем к теме этой статьи и серьезно рассмотрим.mono-repo.

mono-repo

Собственно, я написалreact-routerЭто было упомянуто при анализе исходного кодаmono-repo, сказал тогда, что есть возможность написать отдельныйmono-repoСтатью, эту статью можно рассматривать как заполнение дыры. Итак, мы начинаем сreact-routerНачнем со структуры исходного кодаmono-repoОбщая ситуация, следующая цифраreact-routerСтруктура исходного кода:

Мы обнаружили, что у него естьpackagesпапка с четырьмя элементами в ней:

react-router:ДаReact-RouterОсновная библиотека, которая обрабатывает некоторую общую логику
react-router-config:ДаReact-RouterБиблиотека обработки конфигурации для
react-router-dom: будет указана библиотека, используемая в браузере.react-routerосновная библиотека
react-router-native:служба поддержкиReact-NativeБиблиотека маршрутизации для , также будет ссылатьсяreact-routerосновная библиотека

Эти четыре проекта предназначены дляreactСлужба управления маршрутизацией тесно связана с бизнесом, и для выполнения функции может потребоваться сотрудничество нескольких проектов. Например, чтобы исправить ошибку, нужно одновременно ее изменить.react-router-domа такжеreact-routerЕсли они находятся в разных репозиториях Git, их необходимо изменить, отправить, упаковать, протестировать в двух репозиториях соответственно, а затем для правильной работы необходимо изменить номера версий, которые зависят друг от друга. но используетсяmono-repo, поскольку их код находится в том же репозитории Git, мы находимся вcommitВнутри код двух проектов можно изменить, а затем упаковать, протестировать и выпустить единообразно.lernaСредства управления, зависимости номеров версий тоже автоматически обновляются, что действительно удобно.

lerna

lernaявляется самым известнымmono-repoИнструмент управления , сегодня мы будем использовать его для создания вышеупомянутого проекта общего бизнес-компонента Структура проекта нашей цели выглядит следующим образом:

mono-repo-demo/                  --- 主项目，这是一个Git仓库
  package.json
  packages/
    common/                      --- 共享的业务组件
      package.json
    admin-site/                  --- 柜员网站项目
      package.json
    customer-site/               --- 客户网站项目
      package.json

lerna init

lernaИнициализация проста, сначала создайте пустую папку, затем запустите:

npx lerna init

Эта строка команды поможет мне создать пустойpackagesпапка, аpackage.jsonа такжеlerna.json, вся структура выглядит так:

package.jsonОдно следует отметить, егоprivateдолжен быть установлен наtrue,потому чтоmono-repoСам репозиторий Git не является проектом, это несколько проектов, поэтому он не может опубликовать его напрямую, опубликованный должен бытьpackages/различные подпроекты ниже.

"private": true,

lerna.jsonИнициализация выглядит так:

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

packagesПоле предназначено для обозначения местоположения вашего подпроекта, по умолчаниюpackages/Папка, он же массив, поэтому поддерживает несколько разных местоположений. Еще одна вещь, требующая особого внимания, это то, чтоversionПоле, это поле имеет два типа значений, одно из которых похоже на приведенное выше.0.0.0Такой конкретный номер версии также может бытьindependentэто ключевое слово. если0.0.0Этот конкретный номер версии, затемlernaВсе управляемые подпроекты будут иметь один и тот же номер версии ----0.0.0, если вы установитеindependent, то каждый подпроект может иметь свой номер версии, например, номер версии подпроекта 10.0.0Номер версии подпроекта 2 может быть0.1.0.

Создать подпроект

Теперь нашpackages/Каталог пустой, по нашим предыдущим предположениям нам нужно создать три проекта:

common: Общие бизнес-компоненты не нужно запускать сами, достаточно поставить различные компоненты.
admin-site: сайт кассира, должен быть в состоянии запустить, использоватьcreate-react-appСоздать это
customer-site: клиентский сайт, тоже нужно запустить, или использоватьcreate-react-appСоздайте

Для создания подпроектов вы можете использоватьlernaкоманда для создания:

lerna create <name>

Вы также можете вручную создать папку самостоятельно, здесьcommonЯ буду использовать подпроектlernaкоманда для его создания,lerna create common, после запускаcommonпапка появляется вpackagesНиже:

Это используетlerna createСозданная по умолчанию структура каталогов,__test__Под папкой находится содержимое модульного теста,libНиже приведен код. Так как я собирался использовать его для размещения общих компонентов, я скорректировал структуру каталогов, удалил две папки, сгенерированные по умолчанию, и создал новую.componentsпапка:

Два других работающих сайта используютcreate-react-appсоздано, вpackagesВыполнить в папке:

npx create-react-app admin-site; npx create-react-app customer-site;

После создания нескольких проектов вся структура проекта выглядит так:

согласно сmono-repoСоглашения, названия этих подпроектов лучше всего называть как@<主项目名称>/<子项目名称>, чтобы, когда другие ссылаются на вас, ваши проекты можно было найти вnode_modulesВ том же каталоге имя каталога@<主项目名称>, поэтому мы вручную меняем следующие три подпроектаpackage.jsonвнутриnameдля:

@mono-repo-demo/admin-site
@mono-repo-demo/common
@mono-repo-demo/customer-site

lerna bootstrap

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

lerna bootstrap --hoist

Удалить установленные подпроектыnode_modulesВы можете удалить его вручную или использовать эту команду:

lerna clean

yarn workspace

lerna bootstrap --hoistХотя можно поднять зависимости подпроектов на верхний уровень, его метод относительно груб: сначала запустить каждый подпроект.npm install, после того как все зависимости будут установлены, переместите их на верхний уровеньnode_modules. Это приводит к проблеме: что, если несколько подпроектов зависят от одной и той же сторонней библиотеки, но требуют разных версий? Например, все три наших подпроекта зависят отantd, но их версии не совсем совпадают:

// admin-site
"antd": "3.1.0"

// customer-site
"antd": "3.1.0"

// common
"antd": "4.9.4"

В этом примереadmin-siteа такжеcustomer-siteпотребностиantdверсии3.1.0,ноcommonТребуемая версия4.9.4, если использоватьlerna bootstrap --hoistулучшить,lernaУлучшит самую используемую версию, то есть3.1.0на верхний уровень, затем поместите подпроектnode_modulesвнутриantdВсе удалено. то естьcommonпосетитьantdЕсли вы это сделаете, вы также получите3.1.0версии, что может привести кcommonПроект работает некорректно.

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

или вышеantdНапример, используйтеyarn workspace, Так и будетadmin-siteа такжеcustomer-siteиз3.1.0версия перемещается на верхний уровень, аcommonЯ буду держать себя в рамках проекта4.9.4изantd, чтобы каждый подпроект мог получить необходимые ему зависимости.

yarn workspaceОн также очень прост в использовании,yarn 1.0Вышеупомянутая версия включена по умолчаниюworkspace, поэтому нам нужен только верхний уровеньpackage.jsonПросто добавьте конфигурацию:

// 顶层package.json
{
  "workspaces": [
    "packages/*"
  ]
}

затем вlerna.jsonвнутри указанногоnpmClientдляyarn, и воляuseWorkspacesУстановить какtrue:

// lerna.json
{
  "npmClient": "yarn",
  "useWorkspaces": true
}

использовалyarn workspace, мы не должныlerna bootstrapдля установки зависимостей, но как и раньшеyarn installВсе, он автоматически поможет нам улучшить зависимости, вотyarn installЭффект одинаков, независимо от того, выполняется ли он на верхнем уровне или в любом подпроекте.

Начать подпроект

Теперь, когда мы создали три подпроекта, чтобы запустить подпроект CRA, вы можете перейти в этот каталог и запуститьyarn start, но частое переключение папок доставляет слишком много хлопот. На самом деле естьlernaС помощью , мы можем запустить непосредственно на верхнем уровне, что требует использованияlernaэтой функции:

lerna run [script]

Например, мы запускаем на верхнем уровнеlerna run start, что эквивалентно выполнению каждого подпроектаyarn run startилиnpm run start, в частностиyarnещеnpm, в зависимости от того, где вы находитесьlerna.jsonВнутри этой настройки:

"npmClient": "yarn"

Что, если я хочу запустить команду только в одном из подпроектов? плюс--scopeВот и все, как будто я на верхнем этажеpackage.jsonОн добавил эту строку команды:

// 顶层package.json
{
  "scripts": {
    "start:aSite": "lerna --scope @mono-repo-demo/admin-site run start"
  }
}

Таким образом, мы можем работать непосредственно на верхнем уровнеyarn start:aSite, это запустит сайт администратора, упомянутый ранее, команда, которую он на самом деле запускает, по-прежнемуlerna run start, а затем добавил--scopeчтобы указать запуск в рамках подпроекта администратора,@mono-repo-demo/admin-siteЭто имя нашего подпроекта администратора, который определен в этом подпроекте.package.jsonвнутри:

// 管理员子项目package.json
{
  "name": "@mono-repo-demo/admin-site"
}

Тогда мы действительно бежимyarn start:aSiteБар:

Видя, как знакомый CRA ходит по кругу, видно, что наша конфигурация пока работает хорошо, ха-ха~

Создание общедоступных компонентов

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

//  packages/common/components/WaterForm.js

import { Form, Input, Button } from 'antd';
const layout = {
  labelCol: {
    span: 8,
  },
  wrapperCol: {
    span: 16,
  },
};
const tailLayout = {
  wrapperCol: {
    offset: 8,
    span: 16,
  },
};

const WaterForm = () => {
  const onFinish = (values) => {
    console.log('Success:', values);
  };

  const onFinishFailed = (errorInfo) => {
    console.log('Failed:', errorInfo);
  };

  return (
    <Form
      {...layout}
      name="basic"
      initialValues={{
        remember: true,
      }}
      onFinish={onFinish}
      onFinishFailed={onFinishFailed}
    >
      <Form.Item
        label="姓名"
        name="username"
        rules={[
          {
            required: true,
            message: '请输入姓名',
          },
        ]}
      >
        <Input />
      </Form.Item>

      <Form.Item {...tailLayout}>
        <Button type="primary" htmlType="submit">
          查询
        </Button>
      </Form.Item>
    </Form>
  );
};

export default WaterForm;

Внедрение общедоступных компонентов

Этот компонент написан, мы находимся вadmin-siteСсылка на него в нем.Чтобы сослаться на вышеуказанные компоненты, нам нужноadmin-siteизpackage.jsonДобавьте в него эту зависимость, мы можем изменить ее вручную или использоватьlernaЗаказ:

lerna add @mono-repo-demo/common --scope @mono-repo-demo/admin-site

Эффект этой команды можно изменить вручную вместе с вами.package.jsonэто то же самое:

Затем мы идем кadmin-siteИзмените круг CRA по умолчанию на этот счет за воду:

Затем запустите:

Эм? сообщил об ошибке. . . Вы бы поверили мне, если бы я сказал, что этой ошибки я и ожидал 😜

Общие леса

Посмотрите внимательно на приведенную выше ошибку, о ней сообщается вWaterFormВ этом компоненте сообщение об ошибке говорит: синтаксис jsx не поддерживается, а последние две строки также дают предложение, говорящее нам ввестиbabelкомпилировать. Все они иллюстрируют одну и ту же проблему:Конфигурация babel не влияет на общий подпроект.. Этого и следовало ожидать, нашadmin-siteПричина, по которой он может работать, заключается в том, что CRA помог нам настроить эти леса, иcommonЭтот подпроект не настраивает эти скаффолды и, естественно, не может быть скомпилирован.

Наши подпроектыReactДа, на самом деле они все могут пользоваться одним набором строительных лесов, так что мой план таков:Извлеките все строительные леса CRA, а затем вручную переместите их на верхний уровень, чтобы поделиться тремя подпроектами.

Сначала мы идем вadmin-siteЗапустите следующее:

yarn eject

Эта команда поместит CRAconfigпапка иscriptsпапки всплывают при добавлении их зависимостей вadmin-siteизpackage.jsonв. Итак, что нам нужно сделать, это вручнуюconfigпапка иscriptsПереместите папку на верхний уровень, затем добавьте CRA вpackage.jsonЗависимости также были перемещены на верхний уровень, а конкретный CRA был изменен.package.jsonКакой контент можно передавать черезgitвидимый. Перемещенная структура проекта выглядит так:

Обратите внимание, что сценарий запуска для проекта CRA находится вscriptsпапка, поэтому нам нужно немного изменить ееadmin-siteКоманда запуска:

// admin-site package.json

{
  "scripts": "node ../../scripts/start.js",
}

Теперь мы используемyarn start:aSiteОн по-прежнему будет сообщать об ошибке, поэтому мы продолжаем изменятьbabelпараметр.

первый вconfig/pathsдобавить насpackagesпуть иexportвыйди:

затем изменитьwebpackaконфигурация, вbabel-loaderизincludeДобавьте этот путь к пути:

Теперь снова запустите наш проект, и он будет работать нормально:

Наконец, не забывайте, что есть нашиcustomer-siteО, с этим легко справиться, ведь мы скорректировали структуру всего основного проекта ранее, мы можемcustomer-siteОстальные зависимости были удалены, только@mono-repo-demo/common, а затем настроить сценарий запуска:

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

выпускать

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

Сейчас пытаюсь опубликовать, запускаю

lerna publish

После запуска он позволит вам выбрать новый номер версии:

Я выбираю один здесьminor, Какой номер версии от0.0.0стали0.1.0,ПотомlernaСоответствующие версии зависимостей будут автоматически обновлены, в том числе:

lerna.jsonсобственный номер версии0.1.0:
commonНомер версии становится0.1.0:
admin-siteНомер версии также становится0.1.0, при обновлении зависимогоcommonдля0.1.0:
customer-siteменяется сadmin-siteэто то же самое.

independent version

Вышеупомянутая стратегия выпуска, мы изменилиcommonверсия,admin-siteВерсия тоже стала такой же, по логике это и не нужно,admin-siteпросто обновите зависимостиcommonверсия, ваша собственная версия не обязательно является обновленнойminor, может простоpatch.В этой ситуации,admin-siteДолжна ли быть изменена версия или нет, зависит отlerna.jsonвнутриversionКонфигурация, как упоминалось ранее, если это фиксированный индекс, все версии подпроекта будут согласованными, поэтомуadmin-siteВерсия изменится соответственно, мы изменим ее наindependentбудет другим.

// lerna.json
{
  "version": "independent"
}

Затем я меняю егоcommonПопробуйте опубликовать еще раз:

В пробегеlerna publishМы обнаруживаем, что он позволит вам выбрать версию подпроекта, я могу выбратьcommonобновитесь до0.2.0,а такжеadmin-siteПросто меняются зависимости, вы можете перейти на0.1.1:

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

Суммировать

этоmono-repoКод проекта я почистил и загрузил на GitHub, если он вам нуженmono-repo + reactШаблон проекта, клонируйте его напрямую:GitHub.com/Денис — см....

Давайте рассмотрим основные моменты этой статьи:

Причина в том, что к нам поступило требование от иностранца оплатить коммунальные услуги и иметь возможность продавать вещи.Есть кассовые терминалы и терминалы самообслуживания клиентов.
После анализа мы решили развернуть кассовый терминал и терминал самообслуживания клиентов как две площадки.
Для этих двух сайтов мы создали два новых проекта, чтобы масштабируемость была лучше.
В этих двух проектах много бизнес-компонентов, которые выглядят одинаково, и нам нужно их повторно использовать.
Чтобы повторно использовать эти бизнес-компоненты, мы ввелиmono-repoструктура управления проектами,mono-repoОсобенно подходит для нескольких проектов, которые тесно связаны между собой.
mono-repoСамый известный инструмент —lerna.
lernaМожет автоматически управлять зависимостями между проектами иnode_modules.
использоватьlerna bootstrap --hoistПодпроекты могут бытьnode_modulesПоднимитесь на вершину, решитеnode_modulesДублирующий вопрос.
ноlerna bootstrap --hoistЕсли во время обновления версии зависимостей, на которые ссылается каждый подпроект, несовместимы, будет обновлена наиболее часто используемая версия, в результате чего меньшинство не сможет найти правильные зависимости, и возникнет ошибка.
Для решения проблемы конфликтов версий при продвижении мы ввелиyarn workspaceОн также улучшит наиболее часто используемую версию, но останется меньшинством в собственных зависимостях.node_modulesпод.
Оба проекта CRA в нашем примере имеют свои собственные леса, в то время какcommonБез строительных лесов мы отрегулировали строительные леса и переместили их на верхний уровень, чтобы можно было разделить три проекта.
использовать при публикацииlerna publish, он автоматически обновит внутренние зависимости и обновит номер версии каждого подпроекта.
Правила номеров версий для подпроектов можно найти вlerna.jsonВнутренняя конфигурация, если она настроена как фиксированный номер версии, каждый подпроект сохранит ту же версию, если она настроена какindependentключевое слово, каждый подпроект может иметь свой собственный номер версии.

использованная литература

Официальный сайт Лерны:lerna.js.org/
Yarn workspace: classic.yarn pk more.com/ru/docs/ Я вяжу…

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

Добро пожаловать, чтобы обратить внимание на мой общедоступный номербольшой фронт атакиПолучите высококачественные оригиналы впервые~

Цикл статей "Передовые передовые знания":nuggets.capable/post/684490…

Адрес GitHub с исходным кодом из серии статей «Advanced Front-end Knowledge»:GitHub.com/Денис — см....