Monorepo Vocabulary: Nx, Turborepo, and Modern Workspace Terms (англійською)
Вивчайте словниковий запас monorepo для сучасних команд — робочий простір, конвеєри завдань, віддалений кеш, змінені команди, федерація модулів, набори змін і компроміси між Nx і Turborepo.
Багато швидко зростаючих інженерних команд консолідують свої кодові бази в єдине сховище — monorepo. Інструменти, такі як Nx, Turborepo і Bazel, зробили це практичним в масштабі, вирішуючи ключові проблеми: швидкість збирання, управління залежностями і виявлення змін. Якщо ваша команда переходить на моно- сховище, або ви щойно приєдналися до якогось з них, цей словник допоможе вам швидко впоратися з цим завданням.
Монотеїзм проти політеїзму
Monorepo
monorepo (короткий від * монолітне сховище *) — це єдине сховище з контролем версій, яке містить декілька проектів, пакунків або програм. Всі команди переносять дані до одного і того ж сховища.
«Ми перейшли від 12 окремих репо до монорепо. Тепер, коли змінюється спільна бібліотека, ми можемо побачити, які саме програми зачіпаються в одному запиті на витягування»
Polyrepo
** polyrepo ** (або * multirepo *) — це традиційний підхід, за якого кожен проект або служба має своє власне сховище.
| Monorepo advantages | Polyrepo advantages |
|---|---|
| Atomic cross-project changes | Smaller, focused repos per team |
| Shared tooling and conventions | Independent release cycles |
| Easier code sharing | Simpler permissions model |
| Single source of truth for dependencies | Less accidental coupling |
«Ми обрали monorepo над polyrepo, тому що у нас є спільна система дизайну, яка часто змінюється — атомні затвердження в програмі і бібліотеці набагато чистіші»
Концепція робочого місця
Workspace
У контексті монорепо робочий простір посилається на загальне налаштування сховища, яке пов’ язує всі пакунки разом. Як npm, так і Yarn мають поле workspaces в package.json ; Nx і Turborepo будуються на цьому.
Запустити
npm installна корінь робочого простору — hoisting обробляє спільні залежності для всіх пакунків
Пакунок / Проект
пакунок (у термінології робочого простору npm) або проект (у термінології Nx) є єдиною одиницею у складі монорепо — програмою, бібліотекою або інструментом. Кожна зазвичай має свої package.json і tsconfig.json.
У нас є 8 проектів в монорепо: 3 додатки (
web,mobile,admin) і 5 спільних бібліотек
Спільна бібліотека проти додатка
** Спільна бібліотека ** — це пакунок, від якого залежать інші пакунки — бібліотека компонентів інтерфейсу користувача, пакунок інструментів, клієнт API. App є розгорнутим артефактом — сайт Next.js, служба NestJS, мобільне застосування.
«Спільна бібліотека
@acme/uiвикористовується якweb, так іadmin. Зміни в ньому впливають на обидва»
Будівельні системи
Nx
** Nx ** — потужна система збирання з однієї бази даних і набір інструментів розробника з глибокою інтеграцією для TypeScript, React, Angular, NestJS та інших. Він забезпечує генерацію коду, оркестрацію завдань, візуалізацію залежностей і віддалене кешування.
«Ми використовуємо Nx через графік проекту — він показує точно, які проекти залежать від чого, і
nx affectedвиконує завдання тільки для того, що насправді змінилося»
Turborepo
Turborepo — це високопродуктивний запуск задач для монорепо JavaScript/TypeScript. Вона фокусується на швидких збірках через кешування і паралелізм. Легший і простіший ніж Nx, але з меншою кількістю вбудованих інтеграцій.
«Turborepo було легко прийняти — ми просто додали
turbo.jsonдо нашого існуючого робочого простору і часи збирання впали на 70 %»
Bazel
Bazel — це система збирання, спочатку розроблена в Google. Він підтримує будь- яку мову і використовується у дуже великих моно- сховищах. Складніше налаштовувати, ніж Nx або Turborepo.
Оркестрування завдань
Конвейєр завдань
Конвейєр завдань визначає порядок, в якому завдання виконуються у пакунках, і оголошує залежності між ними. Наприклад, ви можете сказати « перед збиранням програми, спочатку зберігайте всі її залежності від бібліотек »
«Ми визначили конвеєр, де
buildзалежить від^build— Turborepo збирає всі пакети попереднього рівня перед поточним»
Віддалений кеш
** Віддалений кеш ** зберігає вивід задач (збудовані файли, результати тестів) на спільному сервері. Якщо те саме завдання буде виконано знову з тими ж вхідними даними, вивід буде звантажено з кешу, а не переобчислено.
«З ввімкненим віддаленим кешуванням, CI пішов з 12 хвилин до 2 хвилин — кожен пакунок, який не змінився, був просто завантажений з кешу»
Впливові команди
** Впливові команди ** виконують завдання лише для пакунків, які дійсно змінилися з часу базового звіту (зазвичай, головної гілки). Це одна з основних переваг швидкості системи збирання монорепо.
“Запустити
nx affected --target=test, щоб перевірити тільки пакунки, які торкнулися цього PR. Не потрібно запускати тести для пакунків, які не змінилися»
Графік залежностей
Граф залежностей (або Граф проекту) показує, які пакунки залежать від яких інших пакунків. Системи збирання використовують його для визначення порядку збирання і обчислення * впливового * набору.
«Відкрити графік проекту Nx, щоб побачити, які програми будуть вплинути, якщо ми змінимо
@acme/api-client..»
Просунуті шаблони
Модуль Федерації
** Модуль федерації ** є можливістю Webpack і Vite, яка надає змогу окремо розгорнутим програмам спільно використовувати код під час виконання. У монорепо, це дозволяє мікро-фронтенді архітектуру, де кожна команда розгортає незалежно.
«Ми використовуємо модульну федерацію, тому
checkoutмікро-фронтенд може бути розгорнутий без повторного розгортанняshellпрограми»
Changesets
Changesets — це інструмент для керування версіями і журналами змін у моно- сховищах з пакунками, які можна опублікувати. Коли ви вносите зміни, ви додаєте * changeset * — файл з описом змін, у якому описується, чи йдеться про латку, незначне оновлення або велике оновлення.
“Кожен PR, який змінює публічний пакунок, повинен включати файл змін. CI конвеєр читає їх і автоматично перевіряє версії»
Опублікувати робочий процес
** Потік роботи з публікації ** є автоматизованим процесом, який читає файли наборів змін, перевіряє версії пакунків, оновлює журнали змін і публікує їх у npm. Зазвичай виконується на злиття до main.
“Робочий процес публікації виконується при кожному об’ єднанні. Він відкидає версію, теґує commit, і публікує оновлені пакунки в реєстр npm
Звичайні фрази Monorepo
| Phrase | Meaning |
|---|---|
| ”Run affected only” | Only execute tasks for changed packages |
| ”The graph shows it’s downstream” | Other packages depend on this one — a change here cascades |
| ”Cache hit rate is low” | Tasks are not being served from cache — investigate input changes |
| ”We need to hoist this dependency” | Move it to the root package.json so all packages share the same version |
| ”Add a changeset” | Create a changeset file describing what changed and the semver bump |
| ”This is an internal library” | It’s not published to npm — only used within the monorepo |
| ”The pipeline is blocking” | A required task must complete before downstream tasks can start |
Розуміння нюансів: уникнення нерозуміння в дискусіях Monorepo
Робота з монорепо - великими базами коду, що містять кілька проектів - може бути неймовірно ефективною, але вона також вводить новий шар складності в командне спілкування. Для розробників, чия перша мова не є англійською, або які все ще будують свій професійний словник, ці дискусії можуть іноді здатися… густими. Це не тільки про технічні терміни; це про те, як ці терміни використовуються і неявні припущення, які вони несуть. Давайте розглянемо кілька звичайних сценаріїв, де тонка фраза робить велику різницю.
Одна з найчастіших проблем виникає при обговоренні «застосування команд» в таких інструментах, як Nx або Turborepo. Молодший розробник може почути цю фразу і одразу подумати: « Гаразд, це просто список файлів, які було змінено? » Хоча це технічно правильно, але у цій фразі не згадано про важливу річ: команди, які було змінено, є * директивами * — вони вказують інструменту, що робити зі змінами. Розглянемо коментар про перегляд коду від Сари на PR: «Ця зміна, здається, несподівано запускає команду nx affected:build. Чи можете ви подвоїти перевірку, щоб оновлення залежностей у packageA/core справді вплинуло на процес збирання для * всіх * проектів? » Ключовим тут є не лише ідентифікація команди, але й розуміння її призначення — це сигнал, що щось потребує подальшого дослідження і, можливо, більш цілеспрямованої зміни. Аналогічно, коли ви описуєте набори змін, пам’ ятайте, що це не просто « латки ». Вони представляють собою * скоординований набір модифікацій *, розроблений для застосування атомарно, забезпечуючи послідовність у вашій базі коду.
Іншим поширеним джерелом плутанини є поняття « віддаленого кешу ». Розробники можуть почути, що це поняття описується як просто « збереження файлів у іншому місці », але воно набагато складніше. Віддалений кеш — часто керований Nx або Turborepo — це розподілений шар зберігання, який дозволяє проектам в монорепо ефективно ділитися залежностями і будувати артефакти. Це значно зменшує кількість зайвих завантажень, прискорює збирання і забезпечує послідовність між командами. Уявіть повідомлення Slack від Марка: « Щойно запустив nx affected:build — віддалений кеш зберіг мені майже 15 хвилин! Це фантастично для великих проектів. ” Це просте твердження підкреслює * переваги * цієї складної системи.
Нарешті, коли обговорюєте федерацію модулів з Nx, пам’ятайте, що це не просто про спільне використання коду; це про створення справді взаємопов’язаної екосистеми всередині вашого монорепо. Налаштування навколо виставлення і споживання модулів є критичним для його успіху.
Ось приклад, який демонструє, як можна використовувати nx affected:build для перебудови певного проекту у моно- сховищі:
nx affected:buildЦя команда інтелектуально визначає всі проекти, які залежать від зміненого файла, визначає оптимальний порядок збирання і виконує потрібні команди — можливо, використовуючи віддалений кеш для прискорення роботи. Важливо розуміти, що це не просто запуск npm run build в кожному проекті; це високоорганізований процес, керований інструментом монорепо.