Как я могу локально разрабатывать библиотеки Angular 7, которые зависят друг от друга? (проблемы со ссылками на npm) - PullRequest
Новая
       64

Как я могу локально разрабатывать библиотеки Angular 7, которые зависят друг от друга? (проблемы со ссылками на npm)

2 голосов
/ 10 июля 2019

У меня есть два пакета NPM угловой библиотеки:

  • A имеет базовые компоненты
  • A-BC имеет компоненты, которые основаны накомпоненты в A , с дополнительными функциями для интеграции с BC библиотекой

Некоторые компоненты в A-BC импортируются из A как import { MyThing } from 'A';*Пакет 1020 *

A-BC 'package.json: 

"peerDependencies": {
   "A": 1.0.0,
   "BC": 4.0.0
},
"devDependencies": {
   "A": 1.0.0,
   "BC": 4.0.0
}

Мои попытки разработки были:

  1. npm link --only=production in (встроенная версия)A
  2. npm link --only=production in (встроенная версия) A-BC
  3. In my-app, запуск npm link A
  4. In my-app, запуск npm link A-BC
  5. Выполнить my-app

Сбой компиляции my-app, когда A-BC не может найти A установленную где-либо.Они оба перечислены правильно в node_modules прямо рядом друг с другом, как символические папки.Я пробовал это с включенным preserveSymlinks в tsconfig.json и angular.json, но это не помогло.

A может быть прямой зависимостью A-BC, но:

  • И у A, и у A-BC есть forRoot(), который требуется для пакетадля правильной работы приложения, в котором оно установлено. Я не знаю способа динамической передачи параметров forRoot() из A-BC forRoot() в A forRoot()
  • my-app необходимо использовать компоненты A и компоненты A-BC.
  • Если бы A была прямой зависимостью, я не знаю, как бы я смог разработать A-BC локально - что может включать изменение как A-BC, так и иногда A.

В настоящее время мое решение о помощи при помощи бинтов:

  1. Опубликовать A как бета-версию
  2. Установить бета-версию в A-BC и my-app
  3. Ссылка A-BC на my-app через npm link
  4. Если необходимо внести изменения, опубликуйте новую бета-версию A, затем установите ее в my-app и A-BC снова

Может быть альтернативный рабочий процесс установки A через поддержку локальных файлов NPM, но я не уверен.

1 Ответ

2 голосов
/ 14 июля 2019

Я предполагаю, что эти два пакета, о которых вы говорите, были созданы либо с помощью ngCli v6, либо вы объединяете их с уже существующими рабочими пространствами ng, в любом случае давайте попробуем решить вашу проблему.

Я предполагаю, что у вас есть структура рабочего пространства ng, подобная следующей 

...
projects >
  A
  B
  host
...

Где A - это lib. B - это библиотека, которая зависит от A, а host - это приложение, которое использует B.

Когда вы работаете / разрабатываете пакеты ng локально в рабочей области ng, вы должны добавить их псевдонимы в файл root tsconfig.json, например: 

{
 ...
"compilerOptions": {
    ...
    "paths": {
      "a": [
        "dist/a"
      ],
      "a/*": [
        "dist/a/*"
      ],
      "b": [
        "dist/b"
      ],
      "b/*": [
        "dist/b/*"
      ]
    }
  }
}

Это делается автоматически для вас в CLI v7 при создании библиотеки с помощью команды ng new lib {yourLibName}.

Убедившись, что у вас есть эта конфигурация, я бы предложил добавить несколько сценариев к вашему package.json, чтобы собрать свои библиотеки и более просто обслуживать ваше приложение для разработки (host в случае примера) 

"build:a": "ng build A --watch=true",
"build:b": "ng build B --watch=true",
"serve:host": "ng serve host"

После этого, запустив три скрипта один за другим и импортировав соответствующий libModules из lib B в свой Host App и соответствующий libModules из lib A внутри Lib B, вы сможете используйте компоненты lib B, которые зависят от компонентов lib A внутри Host APP.

Имейте в виду, что вы не должны устанавливать две библиотеки в вашем рабочем пространстве, потому что это нарушит импорт внутри ваших проектов, также эти библиотеки не должны быть частью вашего рабочего пространства package.json.

Если вы уже выполнили вышеуказанные действия и ваша проблема не устранена, предоставьте нам ссылку на git-репо или поделитесь файлами tsconfig.json, package.json, angular.json, чтобы мы могли продолжить расследование.

Ответ на дополнительный комментарий

Так что, если я получу ваше дело, вы захотите разработать эти packages, а также установить их в одном рабочем пространстве ng.

Если это так, насколько я знаю, прямого способа сделать это не существует, возможно, вы сможете добиться такого поведения (как вы предложили в комментарии), настроив свои файлы tsconfig.json.

Но, по моему мнению, если вы хотите использовать это ng packages в том же рабочем пространстве, вам не обязательно нажимать их, так как в конце дня это просто еще один набор ngModules, который будет быть "первоклассными гражданами" в приложениях, где вы их предлагаете. Поэтому при сборке для производства они будут потрясены, минимизированы, оптимизированы и так далее. В этом случае вам следует просто расширить сценарий развертывания в вашем package.json таким образом, чтобы перед созданием основного приложения, которое будет зависеть от этих npm/ng/packages, вы собираете эти пакеты. 

"deploy": "ng build A && ng build B && ng build MainApp --production"

В то же время те же самые npm/ng/packages будут по-прежнему доступны для публикации npm, и вы сможете использовать их в других рабочих пространствах. Имейте в виду, что они не должны быть частью одной (рабочей области, в которой они разрабатываются) рабочей области package.json.

...