Как разработать / построить Javascript монорепроект, подобный проектам Visual Studio? - PullRequest
Новая
       113

Как разработать / построить Javascript монорепроект, подобный проектам Visual Studio?

2 голосов
/ 13 апреля 2020

В типичном. NET Базовом проекте (с Visual Studio 2019) у нас есть такая структура: 

Example/
|-- Example.Common/
|   |-- FileExample1.cs
|   |-- FileExample2.cs
|   `-- Example.Common.csproj
|-- Example.WebAPI/
|   |-- Controllers/
|   |-- Program.cs
|   |-- Startup.cs
|   `-- Example.WebAPI.csproj
|-- Example.CLI/
|   |-- Program.cs
|   `-- Example.CLI.csproj
|-- Example.sln

В этом проекте Example.CLI и Example.Web.API ссылаются на Example.Common проект. Файл Example.sln содержит ссылки на все три *.csproj, и у каждого csproj есть свои собственные зависимости, которые могут быть одного из следующих 4 видов: 

<!-- It is a NuGet package (similar to Node.js npm packages) that always resolves from the public nuget.org registry -->
<PackageReference Include="Oracle.ManagedDataAccess.Core" Version="2.18.3" />

<!-- It is local, never resolves from registry -->
<ProjectReference Include="../Example.Common/Example.Common.csproj" />

<!-- Resolves from a machine-wide installed DLL -->
<Reference Include="Global.Dependency.Example" />

<!-- Resolves from a local DLL -->
<Reference Include="Local.Dependency.Example">
  <HintPath>path/to/Local.Dependency.Example.dll</HintPath>
</Reference>

При запуске local во время разработки, если я что-то изменяю в общем исходном коде и запуске проекта CLI он автоматически перестраивает общее и копирует DLL в место назначения, чтобы CLI мог запустить версию с этими последними изменениями. Даже если у меня будет больше проектов в решении, оно просто перестроит проекты, от которых зависит интерфейс командной строки, и если в нем будут какие-либо изменения с момента последнего запуска.

При развертывании он перестраивает все и разрешает локальные зависимости на местном уровне. Моя проблема с пакетами Node.js и NPM заключается в том, что:

  • Когда становится проще для локальной разработки, его сложно развертывать и генерировать образ docker.
  • Когда его легко развернуть и сгенерировать образ docker, он становится трудным для локальной разработки.

Я хочу сделать то же самое в проекте Node.js, поделиться исходным кодом common для использования в web-api и cli, и я хочу разбить каждый из этих компонентов проекта в пакете npm, чтобы каждый пакет мог иметь свои собственные зависимости.

В Node.js проект, у меня похожая структура: 

example/
|-- common/
|   |-- file-example1.js
|   |-- file-example2.js
|   `-- package.json
|-- web-api/
|   |-- controllers/
|   |-- index.js
|   |-- routes.js
|   `-- package.json
|-- cli/
|   |-- index.js
|   `-- package.json
|-- package.json

Проблема в том, как Node.js и npm / yarn / p npm разрешают зависимости. Я пытался использовать Yarn Workspaces, Lerna, Lerna + Yarn Workspaces, но похоже, что все эти инструменты были созданы для пакетов, которые публикуются в реестрах, а не для того, чтобы помочь модульной модели одного проекта.

То, что я хочу, это простой способ сделать это:

  • При разработке local внесите изменения в общий исходный код и запустите web-api или cli с обновленной версией common, без необходимости каждый раз вызывать yarn install или создание npm link вручную
  • При развертывании разрешите зависимости, используя локальный исходный код / ​​сборку, и соберите его в правильном порядке

Я пытался:

  • Протокол пряжи link:, хорошо работает для разработки, но когда я запускаю yarn install --production, он пытается разрешить использование реестра. Не будет работать, потому что ни один из моих пакетов никогда не будет опубликован sh в каком-либо реестре. Протокол
  • NPM file:, работает хорошо для развертывания, но для разработки, когда я делаю изменения в общем пакет, мне нужно удалить общую папку внутри node_modules и снова запустить yarn install. Даже с протоколом file: мне все еще нужен способ сборки в правильном порядке, в противном случае npm / yarn скопирует только исходный код зависимостей в целевую папку node_modules.

1 Ответ

0 голосов
/ 14 апреля 2020

Краткий ответ: 

lerna bootstrap
lerna run dev

bootstrap установит зависимости для соответствующих пакетов. Пример: common должен быть установлен в web-api. Lerna установит common в web-api как node_module.

в package.json, добавив private: true также гарантирует, что lerna publi sh не будет публиковать sh этих проектов.

(длинный ответ:)

С учетом каталога папки 

example/
|-- common/
|   |-- file-example1.js
|   |-- file-example2.js
|   `-- package.json
|-- web-api/
|   |-- controllers/
|   |-- index.js
|   |-- routes.js
|   `-- package.json
|-- package.json

1. Рабочие пространства пряжи .

пример / пакет. json

{
  "private": true,
  "workspaces": ["common", "web-api"]
}

Инициализация пряжи в соответствующих подпапках.

Терминал 

~/example         $ cd ./common
~/example/common  $ yarn init -y
~/example/common  $ cd ../web-api
~/example/web-api $ yarn init -y

в примере / common / package. json

{
  "name": "common",
  "version": 1.0.0
  ...
}

в примере / web-api / package. json

{
  "name" "web-api",
  "dependencies": {
    "common": "1.0.0"
  }
}

Терминал (пока в web-api dir) 

~/example/web-api $ yarn install

В каталоге root должно быть быть node_modules, который должен включать: 

web-api/
common/

yarn создаст символическую ссылку между common и webapi из папки node_modules, которая создается на уровне root.

Тем не менее, yarnpkg принято использовать 

{
  "private": true,
  "workspaces": ["packages/"]
}

Ссылка: Учебное пособие Бен Авад по рабочим пространствам пряжи

2. lerna

Lerna использует рабочие пространства пряжи под капотом ref , но вам требуется конфигурация lerna.json (в которой можно указать требуемый менеджер пакетов npm, пряжа. .. )

lerna. json

{
  "packages": [
    "packages/*"
  ],
  "version": "0.0.0"
}

В lerna есть дополнительные команды, такие как:
- lerna diff common, которые дадут вам git diff с момента последнего коммита, или. - lerna run test, который будет запускать скрипт test в каждом из ваших пакетов. (используйте --scope={common} только для сценария common test).

В create-react-app они также включают поле «changelog», которое, как я предполагаю, будет означать, как люди будут автоматически добавлять префиксы к своим сообщениям.

Ссылка: Ben awad учебник по lerna

...