Монорепо: typescpript & workspaces npm. Настройка и публикация в npm

[@Zoolander]

Публикация в npm необходима или можно обойтись без нее?

Есть ли особенности сборки на jenkins?

[@Zoolander]

Отвечаю сам себе
— публиковать в npm не обязательно, workspaces и так интерпретируются как пакеты — если удалось все включить

Также
У workspaces есть серьезная проблема — любой запуск npm i внутри папки конкретного workspace ломает красивую идею и создает свой локальный node_modules. То есть, может это и не проблема, но декларация workspaces была в том, чтобы иметь один общий node_modules на верхнем уровне — и она не выполняется при npm i внутри папки. Значит, мы имеем сломанное обещание.

PS: попробовал перенести все общие зависимости из пакетов workspaces на самый верхний уровень — да, это работает.

То есть по идее npm i внутри workspace можно вообще не запускать, особенно если все пакеты собираются с очень близкими или одинаковыми зависимостями.

Если же нужна зависимость в отдельном модуле, то алгоритм такой
— записываем зависимость в 'package.json' этого модуля
— запускаем npm i на верхнем уровне
Вуаля — все пакеты в одном верхнем node_modules. Если нужны будут разные версии — просто в 'package.json' их и надо указать.

[@evilandfox]

вставлю свои 5 копеек, ибо имел возможность плотно поработать с npm workspaces)

чтобы выполнить произвольную команду npm для конкретного модуля, выполняем ее в верхнем уровне с указанием модуля через -w

# выполнить для определенного модуля
npm i -D typescript -w packages/common
# выполнить для всех модулей
npm run build -ws

все пакеты будут вынесены в node_modules на верхнем уровне

также небольшой лайфхак в package.json, чтобы при изменении типов typescript кода в модуле не приходилось делать перекомпиляцию для актуализации в других зависимых от нее модулях:

{
  "name": "common-pkg",
  "main": "dist/index.js",
  "typings": "src/index.ts"
}

правда тут есть один нюанс: для такого модуля не будет действовать "skipLibCheck": true