Question

许多人正在使用lerna和/或纱线工作区。

我想从它们迁移到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及其内容）对齐？

有任何提示或示例吗？

谢谢！

Answer 1

在rules_nodejs examples directory中有一些类似于repo结构的示例。这表明（在本例中为Angular应用）具有共享库并正在使用它们，但是此处的原理相同。

通常，您的项目根目录中只有一个WORKSPACE文件。尽管可以为不同的应用程序和库提供多个package.json文件，但它为ts_library规则增加了一些额外的复杂性，因此最好避免使用。 This example repo显示多个package.json文件，但没有Typescript。

对于BUILD（或BUILD.bazel）文件，此处所需的最小值为foo中的一个和bar中的一个（根为一个）。拥有的BUILD文件越多，为源划分的编译单元就越多，因此增加了增量。

然后将ts_library条规则添加到这些BUILD文件中，这些文件可以找到here的文档，它们还显示了直接使用tsc和{{1} }。然后，您可以在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

Bazel与lerna和纱线工作区配合使用

1 个答案: