TL;DR

Не используйте npm link при разработке библиотек JavaScript, используйте вместо этого рабочие области пряжи. Вы сэкономите бесчисленные часы, когда бьетесь головой о стену.

Я работаю с JavaScript около 6 лет и использую npm около последних 4 лет. Я знаю о пряже уже пару лет, но никогда не чувствовал необходимости использовать ее. До этой недели у меня никогда не было серьезных проблем с npm.

Недавно мы достигли стадии зрелости в нашей архитектуре интерфейсного фреймворка и решили, что сейчас самое подходящее время, чтобы разбить большую часть нашего основного кода на отдельные библиотеки. Основная идея - упростить поддержку нашей кодовой базы. Мы используем один и тот же код примерно в десятке кодовых баз. Раньше я создавал библиотеки npm, и у меня никогда не было особых проблем с ними, кроме частных пакетов, установленных через GitHub, но мы отложим это на другой день.

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

Проблема. ссылка npm ужасна. Я пробовал всевозможные комбинации зависимостей и одноранговых зависимостей, но всегда сталкивался с ошибками при сборке типа react не может быть найден или unable to import A from './a' и т. Д. После многих часов биться головой о стену и искать ответы в Google я отказался. Я начал искать другие решения, конечно, я не могу быть единственным человеком, который находит ссылку npm чрезвычайно разочаровывающей.

Одним из первых инструментов, с которыми я столкнулся, был Lerna (https://github.com/lerna/lerna) - Инструмент для управления проектами JavaScript с несколькими пакетами. Идеально! Казалось, что он делал то, что я хотел, но это был довольно здоровенный пакет, больше ориентированный на моно-репозиторий. Наша установка использовала индивидуальные репозитории. Я также не хотел больше тратить время на то, чтобы ничего не вышло. Я еще немного покопался и наткнулся на рабочие места пряжи.

Должен признать, что сначала я был настроен скептически, я никогда не понимал, почему люди используют пряжу вместо npm. В конце концов, у них обоих есть файлы блокировки и они управляют зависимостями из одних и тех же источников 🤷‍♂️. Тем не менее, я следил за документацией (https://classic.yarnpkg.com/en/docs/workspaces/) и получил следующую структуру каталогов:

/<root>
  |
   -> /package-a
  |   |
  |    -> package.json (name: "@org/package-a")
  |
   -> /package-b
  |   |
  |    -> package.json (name: "@org/package-b")
  |
   -> /site
  |   |
  |    -> package.json
  |
   -> package.json (root workspace)

package-a - это основная библиотека, package-b - более самоуверенная библиотека, а site - репозиторий веб-сайтов.

Файл package.json package-a выглядит примерно так

{
  "name": "@org/package-a",
  "version": "1.0.0",
  ...
  "peerDependencies": {
    "react": "^16.3.0"
  }
}

Файл package.json package-b выглядит примерно так

{
  "name": "@org/package-b",
  "version": "1.0.0",
  ...
  "peerDependencies": {
    "@org/package-a": "1.0.0",
    "react": "^16.3.0"
  }
}

А файл package.json site выглядит так

{
  "name": "my-website",
  "version": "1.0.0",
  "dependencies": {
    "react": "^16.3.0",
    "@org/package-a": "1.0.0",
    "@org/package-b": "1.0.0"
  }
}

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

Вот тут-то и пригодится файл package.json в корне «рабочей области». Он выглядит так:

{
  "private": true,
  "workspaces": [
    "package-a",
    "package-b",
    "my-website"
  ]
}

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

После того, как я полностью настроился, это было так же просто, как запустить yarn install из корневого каталога. Немного магии… и вуаля. Три дня, потраченные на борьбу с npm link, были решены за полчаса с использованием рабочих пространств yarn. Теперь я понимаю, почему люди предпочитают пряжу npm!