Как вы делитесь локальными пакетами npm с другими командами в одном репо? - PullRequest
Новая
       17

Как вы делитесь локальными пакетами npm с другими командами в одном репо?

1 голос
/ 10 апреля 2019

Сценарий

Рассмотрим следующую структуру папок: 

/my-service
  /src
  /bin
  /other-package
    /src
    package.json
  package.json

Существует 2 пакета npm: один для my-service и один для other-package.

my-service зависит от other-package.

my-service принадлежит команде A, а other-package принадлежит команде B.

Имейте в виду, команда B будетвсе еще нужно развернуть my-service, когда other-package изменится.Вот почему мы рассматриваем общий репозиторий.

Вопрос

Как вы структурируете эту зависимость так, чтобы опыт разработчиков для обеих команд был разумным?

В идеале, команда B требуется только для установки и сборки other-package и он может делать все, что им нужно в этом каталоге.

Аналогично, команда A должна иметь возможность использовать последнюю версию other-package с минимальным трением влокальное развитие.

Опции

В настоящее время я рассматриваю 2 варианта решения этой проблемы, но не знаю, есть ли лучшие варианты.

Локальная файловая зависимость

В этой опции my-service имеет package.json, который выглядит следующим образом: 

  "dependencies": {
    "other-package": "./other-package"
  },
  "scripts": {
    "build": "npm run build:other-package && npm run build",
    "build:other-package": "cd other-package && npm i && npm run build && cd .."
  }

Локальная зависимость от тарбола

В этой опции my-service имеет package.json, чтовыглядит следующим образом: 

  "dependencies": {
    "other-package": "./other-package/other-package-0.0.1.tgz"
  }

В этом случае команда B должна нести ответственность за запуск npm pack в каталоге other-package, когда будет готова новая версия, обновите package.json в my-service и передайте это Git.

Ответы [ 2 ]

1 голос
/ 10 апреля 2019

Поместите оба пакета в отдельные репозитории, а в файл package.json первого поместите зависимость от репозитория git второго. Это выглядит следующим образом: 

"dependencies": {
  "my-other-package": "git://github.com/user/project.git#commit-ish"
}

Подробнее о доступных параметрах синтаксиса см. Документацию npm .

Таким образом, обе команды могут работать над своими пакетами индивидуально и независимо друг от друга. В то же время можно ссылаться на пакет через его git url, и вы даже можете закрепить определенную ветку, тег или коммит, указав его commit-ish.

В случае, если вы используете GitHub для управления вашими git-репозиториями, вы также можете использовать сокращенный синтаксис: 

"dependencies": {
  "my-other-package": "user/project#commit-ish"
}

Это также работает для частных репозиториев, но только для GitHub. В случае другого решения для git-хостинга вам нужно использовать синтаксис, упомянутый выше.

Поскольку вы упомянули, что зависимая команда хочет использовать последнюю версию без особых проблем, вы можете просто захотеть использовать что-то вроде #master в качестве коммит-иша. Затем на каждом npm install вы получаете последнюю версию, которая зафиксирована в основной ветви.

Обратите внимание, что это приводит к невоспроизводимым сборкам, поскольку вы не можете детерминистически предсказать, что будет установлено. Исходя из моего личного опыта, я бы рекомендовал прикрепить ваши зависимости к конкретному коммиту. Хотя это больше работы по обслуживанию, это приводит к воспроизводимым и предсказуемым установкам, которые, по моему мнению, стоят много, но YMMV.

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

Если по какой-либо причине абсолютно необходимо БЫЛ быть одним хранилищем, и вы не можете использовать описанный мной подход, вас может заинтересовать термин «монорепо». В основном это концепция наличия единого (моно) хранилища для нескольких пакетов. Один из инструментов для управления таким монорепо - это Lerna , и вы можете рассмотреть его поближе.

0 голосов
/ 11 апреля 2019

Те, кто долго разделен, должны быть объединены;те, кто долго объединяются, будут разделены.

Недавно я помог моей команде перейти в монорепо, объединив более 10 репо в одно.У Monorepo есть некоторый недостаток, он оказывает давление на средства контроля версий, когда он становится действительно большим (как у Google).С другой стороны, он облегчает совместное использование кода, повторное использование сценариев сборки, потоки ci, пакетную операцию по истории и файлам git и т. Д.

Типичный подход monorepo одинаково обрабатывает подпроекты. 

/monorepo
  /node_modules <-- shared top level node_modules
  /packages
    /my-service
    /other-package

Еслине по определенной причине, я предлагаю вам оставить оба пакета как родные, а не parent-child.

Когда вы закончите сборку одного из них, скажем, например, other-package, вы поместите ссылку на его dir на верхний уровень * 1012.* dir. 

# in /monorepo
ln -s packages/other-package node_modules

Если вы хотите опробовать инструмент, подобный lerna.js, он поможет вам справиться с тяжелой работой.

Теперь вы можете указать свой my-service/package.json как обычный 

  "dependencies": {
    "other-package": "latest"
  }
...