Использование Bazel с рабочим пространством lerna и yarn - PullRequest
Новая
       7

Использование Bazel с рабочим пространством lerna и yarn

1 голос
/ 22 февраля 2020

Многие люди используют рабочее пространство lerna и / или пряжи.

Я думаю, что либо перейти с них на Bazel, либо просто использовать их вместе с Bazel, хорошо руководствоваться примером проекта.

Например, в настоящее время у меня есть структура каталогов, подобная этой, где foo - это сервер express, а bar - это библиотека, используемая foo, которая основана на машинописи. 

<project root>
├── jest.config.js
├── lerna.json
├── package.json
├── packages
│   ├── bar
│   │   ├── jest.config.js
│   │   ├── package.json
│   │   ├── src
│   │   │   └── index.ts
│   │   ├── test
│   │   │   └── unit
│   │   │       └── index.test.ts
│   │   ├── tsconfig.build.json
│   │   └── tsconfig.json
│   └── foo
│       ├── jest.config.js
│       ├── package.json
│       ├── src
│       │   ├── hello.ts
│       │   └── index.ts
│       ├── test
│       │   ├── integration
│       │   │   └── index.test.ts
│       │   └── unit
│       │       └── index.test.ts
│       ├── tsconfig.build.json
│       └── tsconfig.json
├── tsconfig.build.json
├── tsconfig.json
└── yarn.lock

Как мне согласовать его с Bazel, как вы знаете, WORKSPACE, BUILD и их содержимым?

Любые советы или примеры?

Спасибо!

1 Ответ

2 голосов
/ 22 февраля 2020

В каталоге rules_ nodejs examples есть несколько примеров структур репо. Это показывает (в данном случае приложение Angular), у которого есть общие библиотеки и которые они используют, но принцип здесь тот же.

Как правило, у вас будет только один файл WORKSPACE в root вашего проект. Хотя возможно иметь несколько package.json файлов для разных приложений и библиотек, это добавляет некоторую дополнительную сложность правилам ts_library, которые для начала лучше всего избегать. В этом примере репо показывает несколько package.json файлов, но без Typescript.

Для BUILD (или BUILD.bazel) файлов минимальный необходимый вам здесь - один в foo и один в bar (и один в root). Чем больше файлов BUILD у вас есть, тем больше вы разделяете единицы компиляции для своего источника, увеличивая при этом инкрементность.

Затем добавьте ts_library правила к этим BUILD файлам, документы для которых можно найти здесь , они также показывают разницу между использованием tsc напрямую и ts_library. Затем вы можете определить исходные зависимости между foo и bar, быстрый пример, показанный ниже:

packages/foo/BUILD: 

ts_libaray(
  name = "foo",
  srcs = glob(["src/**/*.ts"]),
  deps = [
    "//packages/bar", <-- this is the source dep for bar
    "@npm//some-package",
  ],
)

packages/bar/BUILD: 

ts_libaray(
  name = "bar",
  srcs = glob(["src/**/*.ts"]),
  deps = [
    "@npm//some-other-package",
  ],
)
...