Использование одноранговых зависимостей с локальными (файл:../some-lib) зависимостями

У меня есть монорепозиторий, в котором много микросервисов. Есть некоторые функции/классы библиотечного типа, которые я хочу сделать доступными для любого микросервиса, который в этом нуждается. Однако, если этот библиотечный пакет объявляет одноранговую зависимость, одноранговая зависимость не будет найдена при запуске кода из того, что зависит от библиотеки.

Рассмотрим эту структуру репо:

  • lib
    • some-library (peerDepends on foo)
      • index.js (requires foo)
      • node_modules будет пустым
  • services
    • some-service (depends on foo, and some-library)
      • index.js (requires some-library)
      • node_modules будет иметь:
      • foo
      • some-library будет символической ссылкой на ../../lib/some-library

При запуске node services/some-service/index.js вы получите сообщение об ошибке «Не удается найти модуль 'foo'», исходящее от lib/some-library/index.js.

Предположительно, это происходит потому, что узел просматривает только lib/some-library/node_modules и любую папку node_modules, которая находится в каталоге-предке. Но поскольку этот код запускался из services/some-service (как рабочего каталога) и из-за символической ссылки в services/some-service/node_modules, я ожидал, что это сработает.

Вот репо, которое вы можете легко клонировать, чтобы увидеть проблему: https://github.com/jthomerson/example-local-dependency-problem

git clone [email protected]:jthomerson/example-local-dependency-problem.git    
cd example-local-dependency-problem    
cd services/some-service    
npm install    
node index.js

Я вижу только два решения:

  • Не используйте peerDependencies внутри библиотеки
  • Установите каждую одноранговую зависимость в корне проекта для локальной разработки и тестирования.

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


node.js npm monorepo peer-dependencies
person Jeremy Thomerson    schedule 11.06.2018    source источник

Ответы (2)


arrow_upward
4
arrow_downward

Как насчет добавления флага --preserve-symlinks? Например.:

node --preserve-symlinks index.js

Вот ссылка на документы

person fketchakeu    schedule 12.06.2018

arrow_upward
0
arrow_downward

У меня была установка с двумя рабочими пространствами, в которой:

рабочая область1

  • общая библиотека
  • модуль-библиотека (одноранговый узел зависит от shared-library)

рабочее пространство2

  • основное приложение (зависит от module-library и shared-library)

Теперь зависимости для проектов рабочей области определены в файле tsconfig.base.json под compilerOptions.paths.

Однако для рабочей области 2, которая не связана с рабочей областью 1, я устанавливаю пакеты (оба через file:. Когда я затем собираю main-app, я получаю сообщение об ошибке, что module-library не может найти shared-library (даже если он установлен в рабочей области 2.

Мне пришлось добавить ./../workspace1/dist/shared-library к compilerOptions.paths в tsconfig.base.json рабочей области 2 (обратите внимание на ссылку на рабочую область 1).

Это, очевидно, объединяет рабочие области в моей файловой системе. Но для целей разработки это идеально.

person Ropstah    schedule 04.10.2020