Базель использует рабочее пространство lerna и yarn

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

Я предполагаю, что либо миграция с них на Bazel, либо просто их совместное использование с Bazel — это хорошо, чтобы ориентироваться на примере проекта.

Например, в настоящее время у меня есть такая структура каталогов, где foo — это экспресс-сервер, а 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 и их содержимое?

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

Спасибо!


node.js typescript lerna bazel bazel-rules
person jjangga    schedule 22.02.2020    source источник

Ответы (1)


arrow_upward
4
arrow_downward

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

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

Для файлов BUILD (или BUILD.bazel) вам потребуется как минимум один в foo и один в bar (и один в корне). Чем больше у вас файлов 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",
  ],
)
person Matt Mackay    schedule 22.02.2020
comment
Большое спасибо, Мэтт! Мне очень помогло! Я надеюсь, что другие также найдут это полезным :) - person jjangga; 23.02.2020