Публикация каждой разрабатываемой версии вашего кода в NPM может быть болезненной. Символические ссылки в Windows? Мех, только не надо. Подмодули Git? Не совсем. Приготовьтесь к легкому экшену с Yalc.
TL; DR (как создать форк и использовать вашу любимую библиотеку)
git clone fork_of_your_favorite_library npm/yarn install (in that fork dir) npm/yarn run build (or similar) npm/yarn install -g yalc yalc publish (still in the fork dir) yalc add fork_of_your_favorite_library (inside your project dir)
Есть много способов разбить код на более мелкие части. Вы можете обойтись без структуры monorepo даже для приложения. Однако что, если ваша команда создает несколько приложений, которые не связаны между собой, но некоторый обмен кода полезен?
Я полагаю, некоторые люди могут просто использовать npm/yarn link., и в большинстве случаев это прекрасно работает, НО каждый в вашей команде должен это делать! Я имею в виду, что если пакет не опубликован в NPM, каждый член команды должен клонировать общий репозиторий, построить его и связать его, прежде чем запускать приложение. Хотели бы вы узнать более простой способ?
Yalc - это небольшой инструмент командной строки, созданный Alex, который позволяет вам публиковать пакет в простом локальном репозитории (просто каталог с файлами). Команда yalc publish учитывает настройки так же, как npm publishкоманда. Вы также можете использовать prepublish или preyalc для любых необходимых шагов сборки.
Когда все будет готово, простоyalc add package в каталоге вашего приложения, который создает полную копию опубликованных файлов в каталог .yalc в корне вашего проекта, добавляет зависимость к package.json в форме file:.yalc/package, и все. Все, что вам нужно сделать сейчас, это зафиксировать каталог .yalc (и yalc.lock файл) в вашем репо, и каждый в вашей команде может использовать пакет, даже не устанавливая Yalc 🎉
Такой подход обеспечивает удивительную прозрачность, поскольку даже без какой-либо явной схемы управления версиями вы знаете, что каждый в команде будет иметь пакет, который на 100% совместим с кодом приложения, поскольку он является частью одного репо и его истории. Yalc предлагает схему управления версиями по умолчанию, основанную на хэше содержимого файлов, которого более чем достаточно для большинства случаев. Вы можете отказаться от этого и использовать обычный семвер, если хотите. Это очень важно, если вы хотите использовать функцию push (публикация + обновление).
В какой-то момент вы можете решить, что пакет достаточно стабилен, и вы хотите просто опубликовать его в NPM, что совершенно нормально (за исключением ненужного беспорядка, который вы там создаете). Тем не менее, я считаю, что Yalc можно использовать в долгосрочной перспективе без каких-либо недостатков, о которых я знаю. Это также дает вам прекрасную возможность сохранить пакет с частным проприетарным кодом скрытым от мира. Если вы когда-либо пытались установить пакет непосредственно из частного репо, вы, возможно, уже поняли, что Yalc предлагает гораздо лучший подход. Или вы пробовали использовать подмодули Git 🙊?
Однако есть одна важная ошибка. Вам необходимо правильно проинструктировать членов команды, иначе у них может возникнуть соблазн изменить содержимое каталога a.yalc. Этого следует избегать ради всеобщего блага. Не стесняйтесь изменять файлы прямо в node_modules для некоторых экспериментов. Любое значимое изменение должно производиться в репозитории с исходным кодом пакета, что приводит к новой сборке и публикации.
Обратите внимание, что Yalc также поддерживает
yalc link, но я не считаю это полезным, потому что всем членам команды нужно будет установить Yalc и вручную связать все необходимые пакеты перед запуском приложения.
Надеюсь, вы найдете это короткое сообщение полезным. Это сэкономило мне и моей команде много времени и сил.
