Проект Ledger Live Monorepo: Частина 2 – Інструменти (Зробіть це блискучим) | Леджер

Ledger Live Monorepo Project: Частина 2 – Інструменти (Зробіть це сяючим) | Леджер

Вихідний вузол: 2985172

Другий запис із серії дописів у блозі «Проект Ledger Live Monorepo», де розробник Ledger розповідає нам історію величезної міграції кодової бази Ledger Live у монорепозиторій. Якщо ви пропустили частину 1, перегляньте її тут:

Встановивши, що архітектура monorepo є життєздатним рішенням, ми почали вивчати доступні інструменти для реалізації нашого плану.

Ведення кількох проектів

У команді Ledger Live ми орієнтуємося в екосистемі JavaScript, і, на щастя для нас, ми вже знали кілька способів обробки кількох проектів за допомогою нашого менеджера пакетів. Деякі з цих можливих рішень включають:

  • NPM (має підтримку робочих областей, але кращі альтернативи),
  • Пряжа 1 (стають занадто старими, кращими та ефективнішими альтернативами),
  • Пряжа ≥ 2 (цікава ідея, але plug n play підтримується не всюди, особливо з React Native),
  • ПНПМ (символічні посилання, створені з урахуванням робочих просторів, ефективні на диску).

Переглянувши все це, ми вирішили піти ПНПМ для:

  • ефективність диска (він використовує віртуальний зберігати та символьні посилання, тому пакунки завантажуються лише один раз, а потім символічно посилаються на ваші node_modules із віртуального магазину),
  • швидкість (оскільки пакети кешуються, наступні інсталяції відбуваються набагато швидше),
  • вбудована підтримка робочих просторів/архітектури monorepo (псевдоніми, оркестровка тощо).

На папері ПНПМ це абсолютна перлина, але символічні посилання були трохи дивними, щоб правильно налаштувати (знову ж таки, особливо з React Native).

Гаразд, наш вибір зроблено, ми підемо з ним ПНПМ.

Оркестровка сценарію

Навіть якщо ПНПМ додає все більше й більше оркестровки до своїх функцій, він все ще не охоплює все, що ми хотіли зробити, наприклад:

  • послідовні збірки,
  • кешування.

Для них ми знайшли двох цікавих претендентів, на які нам потрібно було звернути увагу:

  • NX (командою Angular),
  • Турборепо (який щойно анонсував v1.0.0, коли ми почали над ним працювати, і зараз працюємо з командою Vercel).

Ми перевірили концепцію обох.

NX було набагато більше можливостей, генераторів, автоматизації, чудових графіків залежностей тощо… але це додало багато накладних витрат, і оскільки це досить самовпевнено, нам доведеться дотримуватися їхніх умов.

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

Навіть якщо Турборепо мав менше можливостей, ніж NX, він зробив 2 речі, які ми шукали:

  • Оркестровка збірок з урахуванням дерева залежностей (і одночасних збірок),
  • Кешування (збірки кешуються та «відтворюються», якщо їх код не змінився).

Це, а також те, що ми легко зайшли/кинули, змусили нас вибрати нового хлопця в блоці, TurboRepo.

Версіювання

Ми також розглянули кілька рішень, але зрештою вирішили використати https://github.com/changesets/changesets оскільки це був один із інструментів, рекомендованих TurboRepo, і після невеликого читання документації здавалося, що він відповідає нашим потребам.

Розробникам потрібно буде бути дещо суворішими у своєму процесі розробки та наданні changesets (файл із описом, яку бібліотеку змінює їхній код, ступінь серйозності після півріччя угода та опис зміни). Ці changesets потім використовуються для автоматичного підвищення версії пакетів, що відповідають заданим рівням серйозності, а також автоматизації генерації журнали змін. Крім того, інструменти дозволяють pre release режим, 🍒 на 🍰.

Що далі ?

Визначившись з інструментами, настав час приступати до роботи. У наступній статті блогу ми розповімо про систему збірки та всі функції розробки/автоматизацію/постійну інтеграцію в контексті монорепозиторію.


Валентин ДЕ АЛМЕЙДА
Досвід розробника та основні технології – Ledger Live

Часова мітка:

Більше від Гросбух