3

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

我想要么从它们迁移到 Bazel，要么只将它们与 Bazel 一起使用，以通过示例项目进行指导。

例如，目前，我有一个这样的目录结构，其中 foo 是快速服务器，bar 是 foo 使用的库，两者都基于 typescript。

<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 及其内容？

有什么提示或例子吗？

谢谢！

4

1 回答 1

5

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

通常，您的项目根目录中只有一个 WORKSPACE 文件。虽然可以package.json为不同的应用程序和库提供多个文件，但它会给规则增加一些额外的复杂性，ts_library在开始时，最好避免这些规则。此示例 repo显示了多个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",
  ],
)
于 2020-02-22T13:28:33.140 回答