Переосмысление «одного кольца для управления всеми» менеджера монорепо

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

В своей недавней статье («Lerna больше не поддерживается. Что теперь? — часть 1») я начал миграцию с Lerna на NX в соответствии с требованиями, которые Lerna предъявляла к моему монорепо Pedalboard.

Один комментарий, который я получил, гласил следующее @guitarino:

Что заставило меня 🤔 …

Мои рабочие пространства, хотя и могли бы управляться Lerna, управляются Yarn Workspaces, что имеет гораздо больше смысла и практически работает гораздо лучше. Это и тот факт, что мне нравится идея «правильного инструмента для правильной работы», заставили меня вернуться к чертежной доске.

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

Давайте посмотрим, может ли Yarn справиться с этим. Быстро погуглив, я нашел следующее:

https://classic.yarnpkg.com/en/docs/cli/workspaces#toc-yarn-workspaces-run

Я заменяю вызов NX командой yarn workspace run и проверяю, как это происходит.
То, что у меня было раньше, выглядит следующим образом:

"scripts": {
       "test": "nx run-many --target=test --all",
       "coverage": "yarn test --coverage",
       "lint": "nx run-many --target=lint --all",
       "build": "nx run-many --target=build --all",
       "publish:lerna": "lerna publish --yes --no-verify-access",
       "coverage:combined": "pedalboard-scripts aggregatePackagesCoverage && nyc report --reporter lcov"
   },

Войти в полноэкранный режим Выход из полноэкранного режима

Я изменю это на следующее:

"scripts": {
       "test": "yarn workspaces run test",
       "coverage": "yarn test --coverage",
       "lint": "yarn workspaces run lint",
       "build": "yarn workspaces run build",
       "publish:lerna": "lerna publish --yes --no-verify-access",
       "coverage:combined": "pedalboard-scripts aggregatePackagesCoverage && nyc report --reporter lcov"
   },

Войти в полноэкранный режим Выйти из полноэкранного режима

Все работает хорошо, кроме команды «build». Она не срабатывает, потому что в пакете «components» нет скрипта «build». Это досадно, поскольку NX просто не замечает таких случаев и пропускает их.
Давайте посмотрим, что может предложить Yarn в этом случае…

Хммм, похоже, что команда Yarn [foreach](https://next.yarnpkg.com/cli/workspaces/foreach) знает, как справиться с отсутствующими скриптами.
Но этот плагин требует Yarn v.2 или выше, поэтому давайте быстро обновим его, следуя инструкциям здесь:

После того как мы установили Yarn новой версии, мы можем импортировать плагин, который позволяет нам использовать команду «foreach» следующим образом:

yarn plugin import workspace-tools

Теперь я могу изменить package.json моего корневого проекта следующим образом:

"scripts": {
       "test": "yarn workspaces foreach -p run test",
       "coverage": "yarn test --coverage",
       "lint": "yarn workspaces foreach -p run lint",
       "build": "yarn workspaces foreach -ptv run build",
       "publish:lerna": "lerna publish --yes --no-verify-access",
       "coverage:combined": "pedalboard-scripts aggregatePackagesCoverage && nyc report --reporter lcov"
   },

Войти в полноэкранный режим Выйти из полноэкранного режима

Параметры, которые я использую для команды build, предназначены для параллельного запуска, который по-прежнему учитывает топологический порядок и разрешает зависимости в первую очередь. Символ «v» означает «verbose».

Я проверяю все свои сценарии, и, похоже, все работает как прежде, за вычетом необходимости использования NX для выполнения этих задач. Потрясающе!

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

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

Свежие новости с конференции @NxDevTools —
Я спросил, собираются ли они принять участие во всем рабочем процессе «публикации», который есть у Lerna, и ответ был таков, что они в настоящее время работают над этим. У них там есть несколько проблем:
👇🏻

— Matti Bar-Zeev (@mattibarzeev) 29 апреля 2022 г.

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

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

Эй! Если вам понравилось то, что вы только что прочитали, загляните к @mattibarzeev в Twitter 🍻

Фото Philip Swinburn on Unsplash

Переосмысление «одного кольца для управления всеми» менеджера монорепо

Рекомендуем почитать: