reHi!
Вот в чем дело, у нас есть монорепозиторий. Мы используем Lerna & Yarn с кучей библиотек Angular.
В каждом package.json для пакетов / библиотек у нас есть что-то вроде:
"prepublishOnly": "yarn build <library name goes here>"
Yarn работает для рабочих пространств yarn install
, делает то, что делает. Поскольку мы используем рабочие области, они создают символические ссылки на пакеты. Например, если у нас есть пакет с именем @foo/bar
на верхнем уровне node_modules
, у нас будет node_modules/@foo/bar
символическая ссылка на libs/foo-bar
.
В Yarn Workspaces все в порядке, за исключением того, что материал в node_modules/@foo/bar
не готов к публикации. Во-первых, нам нужно собрать пакет с помощью компилятора Angular CLI.
Мы достигаем этого с помощью уже упомянутого prepublishOnly
сценария в package.json
.
Работает, когда нужно собрать все пакеты. Поток идет:
yarn install
- Создает магию символической ссылки / рабочего пространства.lerna publish --contents dist
- Создает магию монорепо. Лерна увидит, что все пакеты были изменены, и запуститprepublishOnly
для всех пакетов. Таким образом, то, что находится вnode_modules/@foo
, будет законными пакетами NPM (вывод Angular CLI, создающий библиотеки)
Проблема в том, что в одной библиотеке есть модификация.
yarn install
- Создает магию символической ссылки / рабочего пространства. Все элементы вnode_modules/@foo
будут символическими ссылками наlibs/<package-name>
, которые на данный момент являются исходными файлами. Не пакеты NPMlerna publish --contents dist
- Запускается ... и идет Ой, только Пакет А изменился. Так что позвольте мне побороться с этим. Lerna потерпит неудачу из-за того, что другие пакеты внутриnode_modules
НЕ являются законными пакетами NPM.
Мне нужно выяснить, как:
- Всегда собирайте все пакеты при публикации ИЛИ
- Как-то использовать пакеты из реестра NPM в процессе сборки
Я чувствую, что где-то упускаю что-то простое.
Если есть примеры, которые я могу привести, чтобы помочь объяснить, спросите.