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!